- Dillo-dev - lists.mailman3.com

hyphenation in dillo

by sgeerken＠dillo.org

On Tue, Sep 04, corvid wrote: > On http://www.dillo.org/stats/ , it breaks between the month and year. Fixed. Look at the change: it's simple. Unlike before, breaks are also prohibited for "white-space: pre-wrap"; this is how I interpret the CSS spec. Sebastian

Sept. 4, 2012

hyphenation in dillo

by corvid＠lavabit.com

Sebastian wrote: > Just pushed some more changes; should be complete now. Please test > thoroughly. On http://www.dillo.org/stats/ , it breaks between the month and year.

Sept. 4, 2012

hyphenation in dillo

by sgeerken＠dillo.org

> > Just pushed some more changes; should be complete now. Please test > > thoroughly. > > Nice! lwn.net and wikipedia look good for me now, but the text on the > splash screen seems a bit squeezed. I see no difference to the current main repository. I investigated this already some days ago, and found out that paragraphs are handled differenty. Defining a margin for paragraphs works, OTOH. So this is no reason to delay merging. :-) Sebastian

Sept. 4, 2012

hyphenation in dillo

by johannes.hofmann＠gmx.de

On Tue, Sep 04, 2012 at 02:36:29PM +0200, Sebastian Geerken wrote: > > I'm mostly finished with cleaning up the calculation of extremes (used > > for tables). This should already work now, please test it again. > > Just pushed some more changes; should be complete now. Please test > thoroughly. Nice! lwn.net and wikipedia look good for me now, but the text on the splash screen seems a bit squeezed. Johannes

Sept. 4, 2012

hyphenation in dillo

by sgeerken＠dillo.org

> I'm mostly finished with cleaning up the calculation of extremes (used > for tables). This should already work now, please test it again. Just pushed some more changes; should be complete now. Please test thoroughly. Sebastian

Sept. 4, 2012

hyphenation in dillo

by sgeerken＠dillo.org

On Wed, Aug 22, Jorge Arellano Cid wrote: > There're glitches, sure. Just in case you don't yet have a > reliable test case, lwn.net has problems with screen redraw. > Lefthand margin. I'm mostly finished with cleaning up the calculation of extremes (used for tables). This should already work now, please test it again. Sebastian

Aug. 31, 2012

google translate and non-ascii characters

by andreas＠kemnade.info

Hi, On Sat, 2012-08-25 at 20:10 +0000, corvid wrote: > Andreas wrote: > > I tried to use translate.google.com with dillo and it does not work > > with non-ascii characters. I do not know http by heart so that I know > > what character set should be send in the post request but it seems > > not to be what google expects. Words with non-ascii characters are not > > translated and non-ascii characters are turned into questionmarks. > > With our default http_user_agent setting, I see this problem as well. > With it set to a firefox string, translate.google.com seems to work fine. > setting it to a firefox string gives <meta content="text/html; charset=UTF-8" http-equiv="content-type"> instead of <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> but google seem to always want utf-8 from the html form. So it seems to be a clear google bug. Greetings Andreas Kemnade

Aug. 26, 2012

google translate and non-ascii characters

by andreas＠kemnade.info

Hi, On Sat, 25 Aug 2012 20:10:09 +0000 "corvid" <corvid at lavabit.com> wrote: > Andreas wrote: > > I tried to use translate.google.com with dillo and it does not work > > with non-ascii characters. I do not know http by heart so that I know > > what character set should be send in the post request but it seems > > not to be what google expects. Words with non-ascii characters are not > > translated and non-ascii characters are turned into questionmarks. > > With our default http_user_agent setting, I see this problem as well. > With it set to a firefox string, translate.google.com seems to work fine. > I captured a http request and recoded it to utf-8 and send it using netcat. The result was that google correctly translated that without changing user agent. So does google do a workaround for firefox problems, or is google broken and/or is dillo broken here? Greetings Andreas Kemnade

Aug. 26, 2012

google translate and non-ascii characters

by corvid＠lavabit.com

Andreas wrote: > I tried to use translate.google.com with dillo and it does not work > with non-ascii characters. I do not know http by heart so that I know > what character set should be send in the post request but it seems > not to be what google expects. Words with non-ascii characters are not > translated and non-ascii characters are turned into questionmarks. With our default http_user_agent setting, I see this problem as well. With it set to a firefox string, translate.google.com seems to work fine.

Aug. 25, 2012

google translate and non-ascii characters

by andreas＠kemnade.info

Hi, I tried to use translate.google.com with dillo and it does not work with non-ascii characters. I do not know http by heart so that I know what character set should be send in the post request but it seems not to be what google expects. Words with non-ascii characters are not translated and non-ascii characters are turned into questionmarks. Greetings Andreas Kemnade

Aug. 25, 2012

hyphenation in dillo

by sgeerken＠dillo.org

Hi Jorge, On Wed, Aug 22, Jorge Arellano Cid wrote: > Hi Sebastian, > > Sorry for the late reply, part cybernetic part human. > As you noticed there was sometihng weird with the email: > > <quote> > Delivery-date: Mon, 06 Aug 2012 20:58:14 +0200 > Received: from localhost ([127.0.0.1] helo=auriga.wearlab.de) > by kbs62.informatik.uni-bremen.de with esmtp (Exim 4.69) > (envelope-from <dillo-dev-bounces at dillo.org>) > id 1SySVI-00054b-C4; Mon, 06 Aug 2012 20:58:12 +0200 > Received: from lilly.ping.de ([83.97.42.2]) > by kbs62.informatik.uni-bremen.de with smtp (Exim 4.69) > (envelope-from <sgeerken at dillo.org>) id 1StgCZ-0003or-8d > for dillo-dev at auriga.wearlab.de; Tue, 24 Jul 2012 16:35:07 +0200 > Received: (qmail 24854 invoked from network); 24 Jul 2012 14:34:46 -0000 > Received: (ofmipd 188.109.158.229); 24 Jul 2012 14:34:24 -0000 > Date: 24 Jul 2012 16:31:16 +0200 > </quote> > > It took near twelve days to reach me... Yes, there were technical problems. Hopefully solved now. > On Tue, Jul 24, 2012 at 04:31:16PM +0200, Sebastian Geerken wrote: > > Hi! > > > > At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of > > dillo which automatically hyphenates words, using the algorith by Frank > > Liang (which is also used by TeX). It is still quite messy, but works > > already rather stable. Some manual work is neccessary (from > > dillo_hyphen): > > Good work! Thanks. BTW, Johannes did some improvements on the actual hyphenation to reduce memory consumtion; see <http://flpsed.org/hgweb/dillo_hyphen_mem/>. > I've downloaded/compiled and tested a bit: even in spanish! > I like how it breaks paragraphs by squeezing some lines and moving > words around (even without hyphenation). The hyphenating part also > seems OK (I need to test more). Yes, line breaking has been improved a bit, by optimizing per line. May perhaps even be improved by applying TeX's "total fit" algorithm. As for the hyphenation, Liang's approach leads to some errors (including my surname, which is hyphenated as "Ge-er-ken", instead of "Geer-ken"), but this can be dealt with by defining exceptions. > This looks very promising and makes me look forward for the merge > day! So far, dillo has served me very well for reading articles (my > font/size, my colors), and now there's the extra of better line/word > breaking. This will surely also be welcomed by our users. Very good. Yes, I'd like to have this in the main repo rather soon, especially to avoid merging problems with other works. > There're glitches, sure. Just in case you don't yet have a > reliable test case, lwn.net has problems with screen redraw. > Lefthand margin. I know of a problem relating tables, but somehow was not able to construct a test case. I found nothing special about lwn.net, but I'll ask you to test again after the fix. Sebastian

Aug. 25, 2012

hyphenation in dillo

by jcid＠dillo.org

Hi Sebastian, Sorry for the late reply, part cybernetic part human. As you noticed there was sometihng weird with the email: <quote> Delivery-date: Mon, 06 Aug 2012 20:58:14 +0200 Received: from localhost ([127.0.0.1] helo=auriga.wearlab.de) by kbs62.informatik.uni-bremen.de with esmtp (Exim 4.69) (envelope-from <dillo-dev-bounces at dillo.org>) id 1SySVI-00054b-C4; Mon, 06 Aug 2012 20:58:12 +0200 Received: from lilly.ping.de ([83.97.42.2]) by kbs62.informatik.uni-bremen.de with smtp (Exim 4.69) (envelope-from <sgeerken at dillo.org>) id 1StgCZ-0003or-8d for dillo-dev at auriga.wearlab.de; Tue, 24 Jul 2012 16:35:07 +0200 Received: (qmail 24854 invoked from network); 24 Jul 2012 14:34:46 -0000 Received: (ofmipd 188.109.158.229); 24 Jul 2012 14:34:24 -0000 Date: 24 Jul 2012 16:31:16 +0200 </quote> It took near twelve days to reach me... On Tue, Jul 24, 2012 at 04:31:16PM +0200, Sebastian Geerken wrote: > Hi! > > At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of > dillo which automatically hyphenates words, using the algorith by Frank > Liang (which is also used by TeX). It is still quite messy, but works > already rather stable. Some manual work is neccessary (from > dillo_hyphen): Good work! I've downloaded/compiled and tested a bit: even in spanish! I like how it breaks paragraphs by squeezing some lines and moving words around (even without hyphenation). The hyphenating part also seems OK (I need to test more). This looks very promising and makes me look forward for the merge day! So far, dillo has served me very well for reading articles (my font/size, my colors), and now there's the extra of better line/word breaking. This will surely also be welcomed by our users. Very good. There're glitches, sure. Just in case you don't yet have a reliable test case, lwn.net has problems with screen redraw. Lefthand margin. -- Cheers Jorge.-

Aug. 22, 2012

RequestPolicy-like patch

by p37sitdu＠lavabit.com

By the way there is a related bugreport 1072. HTReproduce says > look into dillorc. > there is no filter_auto_requests. This bugreport is outdated, filter_auto_requests is documented in dillorc now.

Aug. 20, 2012

RequestPolicy-like patch

by p37sitdu＠lavabit.com

Fixed memory leak in a_Crossdomain_freeall.

Aug. 8, 2012

RequestPolicy-like patch

by p37sitdu＠lavabit.com

Fixed error messages, they lacked newline. Sample domainrc is attached.

Aug. 8, 2012

RequestPolicy-like patch

by p37sitdu＠lavabit.com

Patch implements functions similar to Firefox addon RequestPolicy. [1] It allows user to control automatic requests more flexible than filter_auto_requests option. Patch removes this option and replaces it with file .dillo/domainrc that looks like this: default deny wikipedia.org .wikimedia.org wikisource.org .wikimedia.org wikitionary.org .wikimedia.org wikiversity.org .wikimedia.org That way most requests are denied, but images on wikipedia are loaded from wikimedia.org without clicking on them. Patterns can start with "." to allow subdomains. Special pattern "*" can be used to allow requests to any domains from some domain (for example if it is a website full of external images) or to allow requests from any domain to some domain (maybe CDN). Without domainrc file all cross-domain requests are denied. [1] https://www.requestpolicy.com/

Aug. 8, 2012

Horizontal scrolling with mouse buttons

by corvid＠lavabit.com

Dennis wrote: > On Tue, 16 Aug 2011 12:03:39 -0400, Jorge Arellano Cid wrote: > > On Mon, Aug 15, 2011 at 02:18:33PM -0400, > > saulgoode at flashingtwelve.brickfilms.com > > wrote: > > > Quoting Jorge Arellano Cid > > > <jcid at dillo.org>: > > > > > > > Please try dillo-3.0-pre, following these directions [1]. > > > >Then report back how it goes. > > > > > > > > [1] http://www.dillo.org/source.html > > > > > > With that build, the horizontal scroll buttons are inactive. To my > > > mind this is satisfactory behavior as it does not interfere with the > > > vertical scrolling of the mouse wheel (previously the only way to > > > restore vertical wheel scrolling was to restart the program). > > > > Good! > > > > This looks like an issue with fltk-1.3. > > > > FWIW, inside fltk-1.3 src/Fl_x.cxx:1443, there's no code to > > handle those buttons. Having something like the following may be > > worth a try (if you're a coder): > > > > if (xevent.xbutton.button == Button4) { > > Fl::e_dy = -1; // Up > > event = FL_MOUSEWHEEL; > > } else if (xevent.xbutton.button == Button5) { > > Fl::e_dy = +1; // Down > > event = FL_MOUSEWHEEL; > > + } else if (xevent.xbutton.button == Button6) { > > + Fl::e_dx = -1; // Left > > + event = FL_MOUSEWHEEL; > > + } else if (xevent.xbutton.button == Button7) { > > + Fl::e_dx = +1; // Right > > + event = FL_MOUSEWHEEL; > > } else { > > Fl::e_state |= (FL_BUTTON1 << (xevent.xbutton.button-1)); > > event = FL_PUSH; > > checkdouble(); > > } > > That doesn't work (for me). Button6/7 aren't defined, or something. > Does anybody have horizontal scrolling working? I saw that there was a commit in June: http://fltk.org/newsgroups.php?s6952+gfltk.commit+v6955+T0 It uses 6/7 instead of Button6/Button7.

Aug. 7, 2012

Ping?

by rogerx.oss＠gmail.com

> On Tue, Jul 24, 2012 at 10:14:45PM +0200, Sebastian Geerken wrote: >Does this work? working... -- Roger http://rogerx.freeshell.org/

Aug. 7, 2012

Ping?

by sgeerken＠dillo.org

Does this work?

July 24, 2012

hyphenation in dillo

by sgeerken＠dillo.org

Hi! At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of dillo which automatically hyphenates words, using the algorith by Frank Liang (which is also used by TeX). It is still quite messy, but works already rather stable. Some manual work is neccessary (from dillo_hyphen): mkdir /usr/local/lib/dillo/hyphenation cp test/hyph-de-1996.pat /usr/local/lib/dillo/hyphenation/de.pat cp test/hyph-en-us.pat /usr/local/lib/dillo/hyphenation/en.pat For other language, the files in the CTAN should be converted. For playing around, try this one: <http://de.wikisource.org/wiki/Spezial:Zuf%C3%A4llige_Seite> :-) Sebastian

July 24, 2012

hyphenation in dillo

by sgeerken＠dillo.org

Hi! At <http://flpsed.org/hgweb/dillo_hyphen/>, you'll find a version of dillo which automatically hyphenates words, using the algorith by Frank Liang (which is also used by TeX). It is still quite messy, but works already rather stable. Some manual work is neccessary (from dillo_hyphen): mkdir /usr/local/lib/dillo/hyphenation cp test/hyph-de-1996.pat /usr/local/lib/dillo/hyphenation/de.pat cp test/hyph-en-us.pat /usr/local/lib/dillo/hyphenation/en.pat For other language, the files in the CTAN should be converted. For playing around, try this one: <http://de.wikisource.org/wiki/Spezial:Zuf%C3%A4llige_Seite> :-) Sebastian

July 24, 2012

Horizontal scrolling with mouse buttons

by dennisn＠dennisn.dyndns.org

On Tue, 16 Aug 2011 12:03:39 -0400, Jorge Arellano Cid wrote: > On Mon, Aug 15, 2011 at 02:18:33PM -0400, > saulgoode at flashingtwelve.brickfilms.com > wrote: > > Quoting Jorge Arellano Cid > > <jcid at dillo.org>: > > > > > Please try dillo-3.0-pre, following these directions [1]. > > >Then report back how it goes. > > > > > > [1] http://www.dillo.org/source.html > > > > With that build, the horizontal scroll buttons are inactive. To my > > mind this is satisfactory behavior as it does not interfere with the > > vertical scrolling of the mouse wheel (previously the only way to > > restore vertical wheel scrolling was to restart the program). > > Good! > > This looks like an issue with fltk-1.3. > > FWIW, inside fltk-1.3 src/Fl_x.cxx:1443, there's no code to > handle those buttons. Having something like the following may be > worth a try (if you're a coder): > > if (xevent.xbutton.button == Button4) { > Fl::e_dy = -1; // Up > event = FL_MOUSEWHEEL; > } else if (xevent.xbutton.button == Button5) { > Fl::e_dy = +1; // Down > event = FL_MOUSEWHEEL; > + } else if (xevent.xbutton.button == Button6) { > + Fl::e_dx = -1; // Left > + event = FL_MOUSEWHEEL; > + } else if (xevent.xbutton.button == Button7) { > + Fl::e_dx = +1; // Right > + event = FL_MOUSEWHEEL; > } else { > Fl::e_state |= (FL_BUTTON1 << (xevent.xbutton.button-1)); > event = FL_PUSH; > checkdouble(); > } That doesn't work (for me). Button6/7 aren't defined, or something. Does anybody have horizontal scrolling working?

July 1, 2012

signed integer overflow in cache.c

by jcid＠dillo.org

On Sat, Jun 16, 2012 at 01:31:01AM +0400, 123 wrote: > In function Cache_client_enqueue variable ClientKey is incremented and > checked for negative values after that (in case of overflow). > > Even though overflow is unlikely, signed integer overflow results in > wraparound on most systems and gcc don't seem to optimize away > overflow check even with -O3 (it only inlines Cache_client_enqueue in > my case) it is better to avoid overflow completely as there are other > compilers and compiler versions. +1. Agreed. I'd add a comment to remember this. e.g. /* integer wraparound/overflow is not defined by C/C++ standards */ -- Cheers Jorge.-

June 18, 2012

dillo.cc cleanup and bugfix

by jcid＠dillo.org

On Sat, Jun 16, 2012 at 02:49:47AM +0400, 123 wrote: > a_UIcmd_open_url and UIcmd_open_url_nbw are identical. Difference is > in argument name and comment. > > Why not remove UIcmd_open_url_nbw and replace it with > a_UIcmd_open_url? For simplicity. It is easier to differentiate the multiple situations: open in a new tab, in a new window, new bw (abstract). As a general rule we're not trying to optimize for size as the most important criteria these days; simplicity has served us better over the years. -- Cheers Jorge.-

June 18, 2012

dillo.cc cleanup and bugfix

by p37sitdu＠lavabit.com

a_UIcmd_open_url and UIcmd_open_url_nbw are identical. Difference is in argument name and comment. Why not remove UIcmd_open_url_nbw and replace it with a_UIcmd_open_url?

June 15, 2012

signed integer overflow in cache.c

by p37sitdu＠lavabit.com

And in case someone thinks it is non-issue: http://thiemonagel.de/2010/01/signed-integer-overflow/

June 15, 2012

signed integer overflow in cache.c

by p37sitdu＠lavabit.com

In function Cache_client_enqueue variable ClientKey is incremented and checked for negative values after that (in case of overflow). Even though overflow is unlikely, signed integer overflow results in wraparound on most systems and gcc don't seem to optimize away overflow check even with -O3 (it only inlines Cache_client_enqueue in my case) it is better to avoid overflow completely as there are other compilers and compiler versions.

June 15, 2012

dillo.cc cleanup and bugfix

by Johannes.Hofmann＠gmx.de

On Thu, Jun 14, 2012 at 11:37:46PM +0400, 123 wrote: > On Thu, Jun 14, 2012 at 07:00:17PM +0000, corvid wrote: > > Johannes wrote: > > > On Sun, Jun 10, 2012 at 10:39:21PM +0400, 123 wrote: > > > > aboutblank.diff removes unnecessary check. > > > > > Removed check for about:blank as start_page, it is not a special case. > > > > > > Committed. > > > > about:blank no longer gives focus to Location. > > Right, it is because a_UIcmd_open_url works differently for NULL and > about:blank. And it is commented in *identical* static function > UIcmd_open_url_nbw. > > I overlooked this difference. If you change it back, add comment > please. > done. Cheers, Johannes

June 15, 2012

Dillo working directory

by p37sitdu＠lavabit.com

And if we really want to change to unmounted directory, then why use "/tmp" instead of "/"? In this case all calls to fl_file_chooser should be changed to use old CWD.

June 15, 2012

Dillo working directory

by p37sitdu＠lavabit.com

On Sun, May 27, 2012 at 04:57:24PM +0400, 123 wrote: > In Paths::init Dillo changes working directory to /tmp. This way every > time I try to open some page stored on the hard disk (Ctrl-O) I have > to start in /tmp. What is the reason for changing WD to /tmp? BTW > oldWorkingDir is not used anywhere. oldWorkingDir is used in fact, it was a mistake. I have searched mailing list and found thread [1] [2] [3] discussing the same issue, but there is no rationale. I also found line in ChangeLog - Fixed Dillo and its dpis to work from "/tmp" (for easy device unmount). Most of the time Dillo is running from $HOME and unmounting it is not common. It may be that someone changes directory to, for example, /mnt, runs dillo there and exits shell (or changes its WD), but it is not common scenario too. The problem with changing directory to /tmp is that open dialog starts in /tmp, it is a bug. As a workaround I am typing "file:" in location, it uses oldWorkingDir then. I have attached patch, it fixes the problem. It is still not finished without removing obsolete oldWorkingDir and using real current directory. Are there any other hidden problems? If not, I will make finished patch. [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-December/009221.html [2] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-December/009223.html [3] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-December/009225.html

June 14, 2012

dillo.cc cleanup and bugfix

by p37sitdu＠lavabit.com

On Thu, Jun 14, 2012 at 07:00:17PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Jun 10, 2012 at 10:39:21PM +0400, 123 wrote: > > > aboutblank.diff removes unnecessary check. > > > > Removed check for about:blank as start_page, it is not a special case. > > > > Committed. > > about:blank no longer gives focus to Location. Right, it is because a_UIcmd_open_url works differently for NULL and about:blank. And it is commented in *identical* static function UIcmd_open_url_nbw. I overlooked this difference. If you change it back, add comment please.

June 14, 2012

dillo.cc cleanup and bugfix

by Johannes.Hofmann＠gmx.de

On Thu, Jun 14, 2012 at 07:00:17PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Jun 10, 2012 at 10:39:21PM +0400, 123 wrote: > > > aboutblank.diff removes unnecessary check. > > > > Removed check for about:blank as start_page, it is not a special case. > > > > Committed. > > about:blank no longer gives focus to Location. > ah, the details... I reverted it.

June 14, 2012

dillo.cc cleanup and bugfix

by corvid＠lavabit.com

Johannes wrote: > On Sun, Jun 10, 2012 at 10:39:21PM +0400, 123 wrote: > > aboutblank.diff removes unnecessary check. > > > Removed check for about:blank as start_page, it is not a special case. > > Committed. about:blank no longer gives focus to Location.

June 14, 2012

[patch] VOIDP2INT, INT2VOIDP and pointer size

by joerg.sonnenberger＠web.de

On Wed, Jun 13, 2012 at 12:38:33PM -0400, Jorge Arellano Cid wrote: > On Tue, Jun 12, 2012 at 10:46:38PM +0200, Johannes Hofmann wrote: > > On Tue, Jun 12, 2012 at 11:25:33PM +0400, 123 wrote: > > > Now (long) is used for converting (void *) to integer. This patch > > > replaces (long) with intptr_t. > > > > > > I don't think this fixes the real problem. When VOIDP2INT and > > > INT2VOIDP macros are used, it is possible that converted type won't > > > fit into intptr_t. It is better to rewrite code that uses these macros > > > in portable way and remove these macros. > > > > Agreed, so let's go for the real fix - step by step. > > Even better would be if we could come up with a case where the > > current scheme causes a real problem - not sure if this is possible, > > some compiler warnings maybe? > > There's an old adage: if it ain't broken don't fix it. > > I'd much prefer if you could focus your patches on real bugs > instead of cleanups or changes to code form. Microsoft uses IL32LLP64 as memory model for Win64. So it certainly "ain't broken". Joerg

June 13, 2012

[patch] VOIDP2INT, INT2VOIDP and pointer size

by jcid＠dillo.org

On Tue, Jun 12, 2012 at 10:46:38PM +0200, Johannes Hofmann wrote: > On Tue, Jun 12, 2012 at 11:25:33PM +0400, 123 wrote: > > Now (long) is used for converting (void *) to integer. This patch > > replaces (long) with intptr_t. > > > > I don't think this fixes the real problem. When VOIDP2INT and > > INT2VOIDP macros are used, it is possible that converted type won't > > fit into intptr_t. It is better to rewrite code that uses these macros > > in portable way and remove these macros. > > Agreed, so let's go for the real fix - step by step. > Even better would be if we could come up with a case where the > current scheme causes a real problem - not sure if this is possible, > some compiler warnings maybe? There's an old adage: if it ain't broken don't fix it. I'd much prefer if you could focus your patches on real bugs instead of cleanups or changes to code form. -- Cheers Jorge.-

June 13, 2012

dillo.cc cleanup and bugfix

by p37sitdu＠lavabit.com

On Tue, Jun 12, 2012 at 10:26:45PM +0200, Johannes Hofmann wrote: > > geometry.diff fixes --geometry flag > > > Fixed --geometry flag. It is --geometry in man page but -geometry in > > > usage and only -geometry is recognized by program. > > I'm not sure here. -geometry seems to be somewhat standard [1] and I > don't want to break people's scripts etc without very good > reason. So for now I adjusted the man page. It is standard for traditional X applications (xclock, xterm etc.) to have only "long" options that start with one dash together with corresponding resource. Standard X tools mostly use XrmParseCommand [1] and you can see examples of options that start with one dash in Xlib documentation. I would even remove short options (like -v) and replace them with standard long options such as -version, but I guess you don't want to break compatibility for it. > > getcmdoption.diff simplifies getCmdOption > > > Simplified getCmdOption. Removed State enum, it was overkill. It is > > > also possible to remove support for mandatory arguments (opt_argc < 0) > > > as it is not used, but it does not add LOC so I left it there. > > Hm, if the patch would fix some bug - even some minor stuff - I would > commit it together with the cleanup, but not just for the reduced > LOC. > Any other takers? Now it looks like someone started writing a state machine for option parsing but then created a separate function for parsing just one option. Or maybe it is copied from legacy code. I will keep it until I find some related bug then, but IMO it is not good to mix cleanup with bugfixes (and it is not good to mix different patches in one in general). [1] http://www.tronche.com/gui/x/xlib/resource-manager/XrmParseCommand.html

June 12, 2012

[patch] VOIDP2INT, INT2VOIDP and pointer size

by Johannes.Hofmann＠gmx.de

On Tue, Jun 12, 2012 at 11:25:33PM +0400, 123 wrote: > Now (long) is used for converting (void *) to integer. This patch > replaces (long) with intptr_t. > > I don't think this fixes the real problem. When VOIDP2INT and > INT2VOIDP macros are used, it is possible that converted type won't > fit into intptr_t. It is better to rewrite code that uses these macros > in portable way and remove these macros. Agreed, so let's go for the real fix - step by step. Even better would be if we could come up with a case where the current scheme causes a real problem - not sure if this is possible, some compiler warnings maybe? Cheers, Johannes

June 12, 2012

[patch] HTML parser bugfix

by Johannes.Hofmann＠gmx.de

On Thu, Jun 07, 2012 at 04:45:42PM +0400, 123 wrote: > On Thu, Jun 07, 2012 at 12:14:06AM +0100, Jeremy Henty wrote: > > > > 123 wrote: > > > > > On Sun, Jun 03, 2012 at 09:00:55PM +0100, Jeremy Henty wrote: > > > > > > If you don't detect and ignore that extra double quote you will > > > > break many pages that every other browser renders perfectly well. > > > > > > Then there should be some logic for detecting double quotes. > > > > I agree. The hard question is: what logic? > > IMO the right way to do it is to implement HTML Standard [1]. When > Html_write_raw is called, parser is in the Data state. When it returns > to Data state again, it is the end of token. > > I have implemented standard comment/DOCTYPE parsing. It is incomplete, > EOF is not handled and DOCTYPE parsing is not changed. Patch is > attached. Next step is to rewrite tag parsing in standard way. > > [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.ht… With your patch text disappears e.g. on http://www.cnas.org/blogs/abumuqawama/2011/04/quote-day.html-0 which was mentioned by Jeremy while it renders ok with current dillo and firefox. I would rather put together a test page that includes all the cases Jeremy brought up plus the reddit one. Also looking into firefox or other browser sources might be a good start. Cheers, Johannes

June 12, 2012

dillo.cc cleanup and bugfix

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Jun 10, 2012 at 10:39:21PM +0400, 123 wrote: > I have split patch into three patches. Good! > > geometry.diff fixes --geometry flag > > Fixed --geometry flag. It is --geometry in man page but -geometry in > > usage and only -geometry is recognized by program. I'm not sure here. -geometry seems to be somewhat standard [1] and I don't want to break people's scripts etc without very good reason. So for now I adjusted the man page. > > getcmdoption.diff simplifies getCmdOption > > Simplified getCmdOption. Removed State enum, it was overkill. It is > > also possible to remove support for mandatory arguments (opt_argc < 0) > > as it is not used, but it does not add LOC so I left it there. Hm, if the patch would fix some bug - even some minor stuff - I would commit it together with the cleanup, but not just for the reduced LOC. Any other takers? > > aboutblank.diff removes unnecessary check. > > Removed check for about:blank as start_page, it is not a special case. Committed. > > Minor fixes (#include order, indentation) are not included. Good. Cheers, Johannes [1] http://www.progsoc.org/tfm/tfm97/node32.html

June 12, 2012

[patch] VOIDP2INT, INT2VOIDP and pointer size

by p37sitdu＠lavabit.com

Now (long) is used for converting (void *) to integer. This patch replaces (long) with intptr_t. I don't think this fixes the real problem. When VOIDP2INT and INT2VOIDP macros are used, it is possible that converted type won't fit into intptr_t. It is better to rewrite code that uses these macros in portable way and remove these macros. Anyway, using intptr_t is better than using (long), (long long) or introducing more autoconf dependency.

June 12, 2012

dillo.cc cleanup and bugfix

by p37sitdu＠lavabit.com

I have split patch into three patches. geometry.diff fixes --geometry flag > Fixed --geometry flag. It is --geometry in man page but -geometry in > usage and only -geometry is recognized by program. getcmdoption.diff simplifies getCmdOption > Simplified getCmdOption. Removed State enum, it was overkill. It is > also possible to remove support for mandatory arguments (opt_argc < 0) > as it is not used, but it does not add LOC so I left it there. aboutblank.diff removes unnecessary check. > Removed check for about:blank as start_page, it is not a special case. Minor fixes (#include order, indentation) are not included.

June 10, 2012

[customercare@dotster.com: Case Number: 01278137 - New Comment Added - ref:_00D30S5t._50060JcXjd:ref]

by jcid＠dillo.org

FYI -- Cheers Jorge.-

June 7, 2012

dillo.org web site

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > Things seems to be working since yesternight. > @all: Please confirm. It all looks good from here. dnsip reports 134.102.206.165 as the only IP for both dillo.org and www.dillo.org . Dillo, links and Firefox all redirect from dillo.org to www.dillo.org . Regards, Jeremy Henty

June 7, 2012

dillo.org web site

by rogerx.oss＠gmail.com

> On Thu, Jun 07, 2012 at 10:43:03AM -0400, Jorge Arellano Cid wrote: >Hi, > > Things seems to be working since yesternight. > @all: Please confirm. ... dang I'm good! -- Roger http://rogerx.freeshell.org/

June 7, 2012

dillo.org web site

by sgeerken＠dillo.org

On Thu, Jun 07, Jorge Arellano Cid wrote: > Things seems to be working since yesternight. > @all: Please confirm. Looks good: --- sg at sg4:~$ nslookup dillo.org Server: 192.168.178.1 Address: 192.168.178.1#53 Non-authoritative answer: Name: dillo.org Address: 134.102.206.165 sg at sg4:~$ nslookup www.dillo.org Server: 192.168.178.1 Address: 192.168.178.1#53 Non-authoritative answer: Name: www.dillo.org Address: 134.102.206.165 -- Also, I don't see any other problems. Sebastian

June 7, 2012

[patch] HTML parser bugfix

by p37sitdu＠lavabit.com

Forgot to attach.

June 7, 2012

dillo.org web site

by jcid＠dillo.org

Hi, Things seems to be working since yesternight. @all: Please confirm. -- Cheers Jorge.-

June 7, 2012

dillo.org web site

by higuita7＠yahoo.co.uk

Hi > Another way to solve the problem may be to point to a working > nameserver elsewhere too (the API seems to allow this option). > I'll ask Andreas K. whether we can point to the wearlab DNS in > the interim. If needed, i recommend the https://dns.he.net/ as a very good free dns hosting, i use it myself higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

June 7, 2012

[patch] HTML parser bugfix

by p37sitdu＠lavabit.com

On Thu, Jun 07, 2012 at 12:14:06AM +0100, Jeremy Henty wrote: > > 123 wrote: > > > On Sun, Jun 03, 2012 at 09:00:55PM +0100, Jeremy Henty wrote: > > > > If you don't detect and ignore that extra double quote you will > > > break many pages that every other browser renders perfectly well. > > > > Then there should be some logic for detecting double quotes. > > I agree. The hard question is: what logic? IMO the right way to do it is to implement HTML Standard [1]. When Html_write_raw is called, parser is in the Data state. When it returns to Data state again, it is the end of token. I have implemented standard comment/DOCTYPE parsing. It is incomplete, EOF is not handled and DOCTYPE parsing is not changed. Patch is attached. Next step is to rewrite tag parsing in standard way. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.ht…

June 7, 2012

[patch] HTML parser bugfix

by onepoint＠starurchin.org

123 wrote: > On Sun, Jun 03, 2012 at 09:00:55PM +0100, Jeremy Henty wrote: > > If you don't detect and ignore that extra double quote you will > > break many pages that every other browser renders perfectly well. > > Then there should be some logic for detecting double quotes. I agree. The hard question is: what logic? > Searching for < inside quotes is not the right way as it breaks > valid pages like reddit main page. Again, I agree. In fact, I decided to experiment with removing Dillo's misquote-detection just because it broke reddit. Unfortunately it is very hard to come up with an algorithm that correctly handles the various quoting horrors that you see all the time, yet also correctly parses embedded javascript fragments like: onclick='alert("clicked")' (IIRC Dillo mis-renders reddit because of embedded javascript like this.) > Can you give examples of real web pages with double quotes? I have attached a bunch of links that I collected after spending a lot of time debugging pages that broke my locally-patched Dillo. (Ignore the file:///... URLs as they obviously won't work for you.) I have also attached the two patches I use. I think the first does the same thing that you propose, although I haven't checked that in detail. The second attempts to copy Firefox's misquote-detection algorithm. I agree that Dillo's misquote-detection isn't good enough, but just taking it out is a step backwards, and it is a mistake to propose changes to it based solely on particular pages that Dillo mis-renders, because any such change needs to be tested against the many other broken pages that Dillo currently renders more or less correctly. Regards, Jeremy Henty

June 6, 2012