- Dillo-dev - lists.mailman3.com

tests that should not be case-sensitive

by johannes.hofmann＠gmx.de

On Wed, Nov 09, 2011 at 08:01:55AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Wed, Nov 09, 2011 at 02:46:00AM +0000, corvid wrote: > > > > I don't want to do anything about this until we get the big patch > > committed, but I just looked through the str(n)cmp calls in dillo, > > and I found: > > > > [...] > > - hostname tests in dns.c. I don't know that code at all, though. > > Is there any reason why it has to treat the hostnames that way? > > If you mean treating them as case sensitive, no, I don't remember > a special reason (although there's a 10% chance or so of it being > for a purpose that I forgot). Same here. > > We can try the other way and check if anything breaks. Ack. Cheers, Johannes

Nov. 9, 2011

tests that should not be case-sensitive

by jcid＠dillo.org

Hi, On Wed, Nov 09, 2011 at 02:46:00AM +0000, corvid wrote: > > I don't want to do anything about this until we get the big patch > committed, but I just looked through the str(n)cmp calls in dillo, > and I found: > > [...] > - hostname tests in dns.c. I don't know that code at all, though. > Is there any reason why it has to treat the hostnames that way? If you mean treating them as case sensitive, no, I don't remember a special reason (although there's a 10% chance or so of it being for a purpose that I forgot). We can try the other way and check if anything breaks. -- Cheers Jorge.-

Nov. 9, 2011

is* character classification

by corvid＠lavabit.com

I was just looking at how the is* functions treat characters with the high bit set. If I set LC_CTYPE to en_US, 0xC0 is alpha, but it understandably isn't in en_US.UTF-8. So I found my way to /usr/share/i18n/locales/ en_US -> en_GB -> i18n And found that: upper 41-5A, C0-D6, D8-DE lower 61-7A, B5, DF-F6, F8-FF alpha 41-5A, 61-7A, AA, B5, BA, C0-D6, D8-F6, F8-FF digit 30-39 space 09-0D, 20 cntrl 00-1F, 7F-9F punct 21-2F, 3A-40, 5B-60, 7B-7E, A0-A9, AB-B4, B6-B9, BB-BF, D7, F7 graph 21-7E, A0-FF print 20-7E, A0-FF xdigit 30-39, 41-46, 61-66 blank 9, 20 In dillo: isupper not used islower not used isalpha cssparser, html isdigit doesn't matter isalnum cssparser, html, datauri, downloads, dlib.h dIsalnum url isspace cssparser, html, keys, dlib.h, findtext.hh dIsspace colors, src/cookies, misc, dpi/cookies, file, ftp, dlib iscntrl keys, auth, misc ispunct textblock isgraph not used isprint dlib isxdigit doesn't matter isblank not used isascii not used I'm not sure that any real harm is done in these cases, but it might not be a bad idea to check that it's ascii when we only want ascii.

Nov. 9, 2011

tests that should not be case-sensitive

by corvid＠lavabit.com

I don't want to do anything about this until we get the big patch committed, but I just looked through the str(n)cmp calls in dillo, and I found: - a bunch of cases where we test url strings with the scheme included. - hostname tests in dns.c. I don't know that code at all, though. Is there any reason why it has to treat the hostnames that way? - generic font-family names in styleengine.cc. CSS 2.1 says: "All CSS syntax is case-insensitive within the ASCII range (i.e., [a-z] and [A-Z] are equivalent), except for parts that are not under the control of CSS. For example, the case-sensitivity of values of the HTML attributes "id" and "class", of font names, and of URIs lies outside the scope of this specification. Note in particular that element names are case-insensitive in HTML, but case-sensitive in XML." ...although I know "@charset" has to be lowercase, so this might not be the ultimate answer, but I didn't see anything suggesting otherwise.

Nov. 9, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > So all uppercase macros then or just not trying to inline and use a > normal function. Here's what I have now: http://www.dillo.org/test/ascii_strcasecmp3.diff

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Tue, Nov 08, 2011 at 08:15:57PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Nov 08, 2011 at 05:42:26PM +0000, corvid wrote: > > > I think I'll go with D_ASCII_TOUPPER because the argument gets > > > evaluated more than once, and we don't want nasty surprises. > > > > Hm, not sure what you mean. An inline function should behave just as > > a normal function that's the nice thing about them. > > If I'm in dlib.h and it's C90, can I use inline? I was under the > impression that I couldn't. Argh, I knew there was a catch :-) So all uppercase macros then or just not trying to inline and use a normal function. Cheers, Johannes

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > On Tue, Nov 08, 2011 at 05:42:26PM +0000, corvid wrote: > > I think I'll go with D_ASCII_TOUPPER because the argument gets > > evaluated more than once, and we don't want nasty surprises. > > Hm, not sure what you mean. An inline function should behave just as > a normal function that's the nice thing about them. If I'm in dlib.h and it's C90, can I use inline? I was under the impression that I couldn't.

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Tue, Nov 08, 2011 at 05:42:26PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > > > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > I'd just go with the approach in your first patch. > > > > > > > > All right then. Do you have any thoughts on what function names > > > > would be least unwieldy / most descriptive / best fitting in > > > > with their surroundings? > > > > > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > > > > > Let's see what others do: > > > > > > * KDE: kAsciiToUpper() [1] > > > * glib: g_ascii_toupper() [2] > > > * ffmpeg: av_toupper() [3] > > > * libevent: evutil_ascii_strcasecmp() [4] > > > > > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. > > > > +1 > > I think I'll go with D_ASCII_TOUPPER because the argument gets > evaluated more than once, and we don't want nasty surprises. Hm, not sure what you mean. An inline function should behave just as a normal function that's the nice thing about them. Let's test: #include <stdio.h> static inline int test(int i) { return i > 0 ? i - 1 : i; } #define TEST(i) ((i) > 0 ? (i) - 1 : (i)) int main (int argc, char **argv) { int i = atoi(argv[1]); int j = atoi(argv[1]); printf("%d\n", test(i++)); printf("%d\n", TEST(j++)); } ./inline 2 1 2 Cheers, Johannes

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

And *sigh* dStristr -> dStriAsciiStr, which seems more readable than dStrAsciiIStr.

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Jorge wrote: > On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > > Johannes wrote: > > > > I'd just go with the approach in your first patch. > > > > > > All right then. Do you have any thoughts on what function names > > > would be least unwieldy / most descriptive / best fitting in > > > with their surroundings? > > > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > > > Let's see what others do: > > > > * KDE: kAsciiToUpper() [1] > > * glib: g_ascii_toupper() [2] > > * ffmpeg: av_toupper() [3] > > * libevent: evutil_ascii_strcasecmp() [4] > > > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. > > +1 I think I'll go with D_ASCII_TOUPPER because the argument gets evaluated more than once, and we don't want nasty surprises. (I'm tempted to say "Or ASCII_TOUPPER?", but it'd be nice for the whole topic to come to an end, wouldn't it? :)

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > Johannes wrote: > > > I'd just go with the approach in your first patch. > > > > All right then. Do you have any thoughts on what function names > > would be least unwieldy / most descriptive / best fitting in > > with their surroundings? > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > Let's see what others do: > > * KDE: kAsciiToUpper() [1] > * glib: g_ascii_toupper() [2] > * ffmpeg: av_toupper() [3] > * libevent: evutil_ascii_strcasecmp() [4] > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. +1 -- Cheers Jorge.-

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > Johannes wrote: > > I'd just go with the approach in your first patch. > > All right then. Do you have any thoughts on what function names > would be least unwieldy / most descriptive / best fitting in > with their surroundings? > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). Let's see what others do: * KDE: kAsciiToUpper() [1] * glib: g_ascii_toupper() [2] * ffmpeg: av_toupper() [3] * libevent: evutil_ascii_strcasecmp() [4] So dAsciiToupper() and dStrAsciiCasecmp() look good to me. Cheers, Johannes [1] http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kascii_8h.html [2] http://developer.gnome.org/glib/2.28/glib-String-Utility-Functions.html [3] http://permalink.gmane.org/gmane.comp.video.ffmpeg.cvs/43420 [4] http://www.wangafu.net/~nickm/libevent-2.0/doxygen/html/util_8h.html

Nov. 7, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > I'd just go with the approach in your first patch. All right then. Do you have any thoughts on what function names would be least unwieldy / most descriptive / best fitting in with their surroundings? I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp().

Nov. 6, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Sun, Nov 06, 2011 at 04:03:47AM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > Or maybe > > > test for strncasecmp_l() in configure and provide a custom solution > > > if it doesn't exist? > > > > I'm willing to give that a look as well. At first I was reluctant to > > have extra locale calls when the string functions are so cheap to > > begin with, but... > > I thought the extra argument to the *_l functions was a string like "C", > but it's a locale_t, which also appears to be something new. This makes > it not very nice to simulate. Hmph. I'd just go with the approach in your first patch.

Nov. 6, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > Or maybe > > test for strncasecmp_l() in configure and provide a custom solution > > if it doesn't exist? > > I'm willing to give that a look as well. At first I was reluctant to > have extra locale calls when the string functions are so cheap to > begin with, but... I thought the extra argument to the *_l functions was a string like "C", but it's a locale_t, which also appears to be something new. This makes it not very nice to simulate. Hmph.

Nov. 6, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

On Sat, Nov 05, 2011 at 06:45:19PM +0000, corvid wrote: > Johannes wrote: > > Hm, what's the point of the dynamic check? We don't > > want our case insensitive compare function to depend on the user locale, > > so I would say using strcasecmp(3) and tolower(3) is just wrong in our > > case - even if it happens to return the right values in some setups. > > Why not just use a custom function as in the first patch? > > I was curious whether something closer to what Jorge was talking about > would turn out to be more pleasing in some way, and maybe a tad quicker, > for that matter, with their optimized functions, but...yeah, it didn't > really look nicer to me, either. My idea was to have a custom function for the turkish locale (eventually extendable to a bigger set if the need arises), and to use the defaults for all the other cases. With the custom function handling the special case(s), and not handling all characters as special. > > Or maybe > > test for strncasecmp_l() in configure and provide a custom solution > > if it doesn't exist? Yes, this would also add to the solution. > I'm willing to give that a look as well. At first I was reluctant to > have extra locale calls when the string functions are so cheap to > begin with, but... -- Cheers Jorge.-

Nov. 5, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > Hm, what's the point of the dynamic check? We don't > want our case insensitive compare function to depend on the user locale, > so I would say using strcasecmp(3) and tolower(3) is just wrong in our > case - even if it happens to return the right values in some setups. > Why not just use a custom function as in the first patch? I was curious whether something closer to what Jorge was talking about would turn out to be more pleasing in some way, and maybe a tad quicker, for that matter, with their optimized functions, but...yeah, it didn't really look nicer to me, either. > Or maybe > test for strncasecmp_l() in configure and provide a custom solution > if it doesn't exist? I'm willing to give that a look as well. At first I was reluctant to have extra locale calls when the string functions are so cheap to begin with, but...

Nov. 5, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Fri, Nov 04, 2011 at 02:41:28AM +0000, corvid wrote: > Jorge wrote: > > On Mon, Oct 31, 2011 at 04:03:38AM +0000, corvid wrote: > > > Jorge wrote: > > > > From a distance this global change looks to me like exposing ourselves > > > > to more troubles. In other words, why not: > > > > > > > > int dStrcasecmp(...) > > > > { > > > > if (locale has special rules) > > > > special treatment > > > > else > > > > strcasecmp(...) > > > > } > > > > > > > > Disclaimer: I haven't studied the problem in detail. > > > > > > Having to know about the locales would be trouble. > > > Judging by the wikipedia page, we'd have to look for 'tr' and 'az' > > > for sure, and they've been considering switching back to Latin > > > script in Kazakhstan, and probably not Tatar because they're mostly > > > Cyrillic, but probably yes to Crimean Tatar because it looks like > > > they're a bit more Latin than Cyrillic at the moment. > > > > > > So it's a touchy enough situation that different libc's may have > > > different ideas of it all, and individual ones will change as > > > circumstances change, > > > > If libc has not nailed it already, it must be hard to solve > > the problem in a generic way. > > > > > and it would make more sense to have a > > > test like checking whether toupper('i') == 'I'. > > > > > > And better than that would be to go through the whole ASCII alphabet > > > at initialization time and see whether everything is as we wish, and > > > then set some ptrs to functions accordingly. > > > > +1 > > > > (or just test the subset we know we can handle). > > Here's what I ended up with when I added in some initialization on the > dlib side: http://www.dillo.org/test/ascii_strcasecmp2.diff > Hm, what's the point of the dynamic check? We don't want our case insensitive compare function to depend on the user locale, so I would say using strcasecmp(3) and tolower(3) is just wrong in our case - even if it happens to return the right values in some setups. Why not just use a custom function as in the first patch? Or maybe test for strncasecmp_l() in configure and provide a custom solution if it doesn't exist? Cheers, Johannes

Nov. 5, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Jorge wrote: > On Mon, Oct 31, 2011 at 04:03:38AM +0000, corvid wrote: > > Jorge wrote: > > > From a distance this global change looks to me like exposing ourselves > > > to more troubles. In other words, why not: > > > > > > int dStrcasecmp(...) > > > { > > > if (locale has special rules) > > > special treatment > > > else > > > strcasecmp(...) > > > } > > > > > > Disclaimer: I haven't studied the problem in detail. > > > > Having to know about the locales would be trouble. > > Judging by the wikipedia page, we'd have to look for 'tr' and 'az' > > for sure, and they've been considering switching back to Latin > > script in Kazakhstan, and probably not Tatar because they're mostly > > Cyrillic, but probably yes to Crimean Tatar because it looks like > > they're a bit more Latin than Cyrillic at the moment. > > > > So it's a touchy enough situation that different libc's may have > > different ideas of it all, and individual ones will change as > > circumstances change, > > If libc has not nailed it already, it must be hard to solve > the problem in a generic way. > > > and it would make more sense to have a > > test like checking whether toupper('i') == 'I'. > > > > And better than that would be to go through the whole ASCII alphabet > > at initialization time and see whether everything is as we wish, and > > then set some ptrs to functions accordingly. > > +1 > > (or just test the subset we know we can handle). Here's what I ended up with when I added in some initialization on the dlib side: http://www.dillo.org/test/ascii_strcasecmp2.diff

Nov. 4, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Jorge wrote: > On Mon, Oct 31, 2011 at 04:03:38AM +0000, corvid wrote: > > Jorge wrote: > > > From a distance this global change looks to me like exposing ourselves > > > to more troubles. In other words, why not: > > > > > > int dStrcasecmp(...) > > > { > > > if (locale has special rules) > > > special treatment > > > else > > > strcasecmp(...) > > > } > > > > > > Disclaimer: I haven't studied the problem in detail. > > > > Having to know about the locales would be trouble. > > Judging by the wikipedia page, we'd have to look for 'tr' and 'az' > > for sure, and they've been considering switching back to Latin > > script in Kazakhstan, and probably not Tatar because they're mostly > > Cyrillic, but probably yes to Crimean Tatar because it looks like > > they're a bit more Latin than Cyrillic at the moment. > > > > So it's a touchy enough situation that different libc's may have > > different ideas of it all, and individual ones will change as > > circumstances change, > > If libc has not nailed it already, it must be hard to solve > the problem in a generic way. There are strcasecmp_l() and strncasecmp_l(), but they were only introduced in a very recent version of posix. http://www.gnu.org/s/hello/manual/gnulib/strcasecmp_005fl.html says "This function is missing on many platforms: MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin, mingw, Interix 3.5, BeOS." As for whether strcasecmp_l() is cheap, in any case, I don't know.

Oct. 31, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

On Mon, Oct 31, 2011 at 04:03:38AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote: > > > On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote: > > > > > > > > Here's an idea of what we'd get: > > > > > > > > http://www.dillo.org/test/ascii_strcasecmp.diff > > > > > > > > - The naming is clear but kind of ugly. > > > > - I haven't added explanatory comments yet. > > > > - For the moment, it just #defines dStr(n)casecmp to the > > > > ASCII version because there are a bunch of them, but I'd > > > > go through and change the calls. > > > > > > > > Thoughts? > > > > > > I think it's nasty, but the right way to fix this. > > > > Yeah. Ater all locales/utf-8 is seldom a simple thing to handle right. > > > > If we'd have to: > > > > s/dStrcasecmp/dStrASCIIcasecmp/g > > s/dStrncasecmp/dStrnASCIIcasecmp/g > > > > then I'd keep the old function name and explain in the function's > > comment why it is restricted to, or handled in the new way. > > Calling it 'strcasecmp' when it isn't really strcasecmp seems dangerous. Good point... > > From a distance this global change looks to me like exposing ourselves > > to more troubles. In other words, why not: > > > > int dStrcasecmp(...) > > { > > if (locale has special rules) > > special treatment > > else > > strcasecmp(...) > > } > > > > Disclaimer: I haven't studied the problem in detail. > > Having to know about the locales would be trouble. > Judging by the wikipedia page, we'd have to look for 'tr' and 'az' > for sure, and they've been considering switching back to Latin > script in Kazakhstan, and probably not Tatar because they're mostly > Cyrillic, but probably yes to Crimean Tatar because it looks like > they're a bit more Latin than Cyrillic at the moment. > > So it's a touchy enough situation that different libc's may have > different ideas of it all, and individual ones will change as > circumstances change, If libc has not nailed it already, it must be hard to solve the problem in a generic way. > and it would make more sense to have a > test like checking whether toupper('i') == 'I'. > > And better than that would be to go through the whole ASCII alphabet > at initialization time and see whether everything is as we wish, and > then set some ptrs to functions accordingly. +1 (or just test the subset we know we can handle). -- Cheers Jorge.-

Oct. 31, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {lleft, right}-tab

by jcid＠dillo.org

On Sun, Oct 30, 2011 at 07:54:41PM +0000, Jeremy Henty wrote: > Benjamin Johnson wrote: > > Jorge wrote: > > > > >> Jeremy Henty wrote: > > >> >> > Another case of "let's be like the other browsers". See: > > >> >> > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > > > ... yeah some term emulators default to Ctrl+{PgUp,PgDn} > > > It looks OK to me. > > > Comments? > > > -- Cheers > > > Jorge.- > > > > [...] > > > > So let's keep it if Chrome does it, but I wouldn't worry about > > Konsole and GNOME Terminal and Terminal.app and mxterm and aterm and > > GNU screen and whatever else people are using to run /bin/sh. If > > you really think Dillo should act like a Unix shell, you have your > > personal keysrc. > > Personally, when I submitted the patch my only motivation was to be > compatible with other browsers. I hadn't thought at all about > terminal emulators (or any other tabbed desktop applications). My point was: * the URL shows Chrome already decided to include the binding. * Most bindings in new apps. have roots in older apps. (brain wiring is hard to change). -- Cheers Jorge.-

Oct. 31, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Jorge wrote: > On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote: > > On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote: > > > > > > Here's an idea of what we'd get: > > > > > > http://www.dillo.org/test/ascii_strcasecmp.diff > > > > > > - The naming is clear but kind of ugly. > > > - I haven't added explanatory comments yet. > > > - For the moment, it just #defines dStr(n)casecmp to the > > > ASCII version because there are a bunch of them, but I'd > > > go through and change the calls. > > > > > > Thoughts? > > > > I think it's nasty, but the right way to fix this. > > Yeah. Ater all locales/utf-8 is seldom a simple thing to handle right. > > If we'd have to: > > s/dStrcasecmp/dStrASCIIcasecmp/g > s/dStrncasecmp/dStrnASCIIcasecmp/g > > then I'd keep the old function name and explain in the function's > comment why it is restricted to, or handled in the new way. Calling it 'strcasecmp' when it isn't really strcasecmp seems dangerous. > From a distance this global change looks to me like exposing ourselves > to more troubles. In other words, why not: > > int dStrcasecmp(...) > { > if (locale has special rules) > special treatment > else > strcasecmp(...) > } > > Disclaimer: I haven't studied the problem in detail. Having to know about the locales would be trouble. Judging by the wikipedia page, we'd have to look for 'tr' and 'az' for sure, and they've been considering switching back to Latin script in Kazakhstan, and probably not Tatar because they're mostly Cyrillic, but probably yes to Crimean Tatar because it looks like they're a bit more Latin than Cyrillic at the moment. So it's a touchy enough situation that different libc's may have different ideas of it all, and individual ones will change as circumstances change, and it would make more sense to have a test like checking whether toupper('i') == 'I'. And better than that would be to go through the whole ASCII alphabet at initialization time and see whether everything is as we wish, and then set some ptrs to functions accordingly.

Oct. 31, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {lleft, right}-tab

by onepoint＠starurchin.org

Benjamin Johnson wrote: > Jorge wrote: > > >> Jeremy Henty wrote: > >> >> > Another case of "let's be like the other browsers". See: > >> >> > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > > ... yeah some term emulators default to Ctrl+{PgUp,PgDn} > > It looks OK to me. > > Comments? > > -- Cheers > > Jorge.- > > [...] > > So let's keep it if Chrome does it, but I wouldn't worry about > Konsole and GNOME Terminal and Terminal.app and mxterm and aterm and > GNU screen and whatever else people are using to run /bin/sh. If > you really think Dillo should act like a Unix shell, you have your > personal keysrc. Personally, when I submitted the patch my only motivation was to be compatible with other browsers. I hadn't thought at all about terminal emulators (or any other tabbed desktop applications). Regards, Jeremy Henty

Oct. 30, 2011

view src

by corvid＠lavabit.com

Jorge wrote: > Have you had any trouble with it? > If not, I'd like to commit it. It feels a little surprising to have to press reload to get updated src, but it's an improvement over having it forbidden. Is the vsource case still needed in nav?

Oct. 30, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {lleft, right}-tab

by rogerx.oss＠gmail.com

> On Sun, Oct 30, 2011 at 11:35:43AM -0400, Benjamin Johnson wrote: >Jorge wrote: > >> > Jeremy Henty wrote: >> > >> > Another case of "let's be like the other browsers". See: >> > >> > >> http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… >> ... yeah some term emulators default to Ctrl+{PgUp,PgDn} >> It looks OK to me. >> Comments? >> -- Cheers >> Jorge.- > >I don't have a problem with the patch, but I do question the reasoning. >Dillo is a web browser, so most users will logically expect it to behave >like other web browsers they have used. Following Chrome, for instance, >is quite logical since it's a well-known browser many users are probably >familiar with. > >On the other hand, most users *don't* expect Dillo to behave like a >terminal emulator, which is a different kind of program entirely. It's >the same thing as with the input box keys. At best it's mildly confusing, >and if it conflicts with the expected behavior, it can cause a great deal >of frustration. Frustration hurts usability and drives away potential >users. > >So let's keep it if Chrome does it, but I wouldn't worry about Konsole and >GNOME Terminal and Terminal.app and mxterm and aterm and GNU screen and >whatever else people are using to run /bin/sh. If you really think Dillo >should act like a Unix shell, you have your personal keysrc. This last paragraph I find humorous. Although I haven't got the slightest clue as to what these keys do in a normal browser -- as simple as it even sounds, but I get two to five times more tasks completed in a shell rather then using a GUI browser. Funny. The shell must have done something right compared to GUI -- like keep our hands on the keyboard like the good typing teacher taught!!! -- Roger http://rogerx.freeshell.org/

Oct. 30, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab

by onepoint＠starurchin.org

corvid wrote: > Jorge wrote: > > On Mon, Oct 24, 2011 at 10:35:02AM +0100, Jeremy Henty wrote: > > > Jeremy Henty wrote: > > > > > > > > Another case of "let's be like the other browsers". See: > > > > > > > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > > > > ... yeah some term emulators default to Ctrl+{PgUp,PgDn} > > > > It looks OK to me. > > Comments? > > *has no objection* OK, I have pushed it. Regards, Jeremy Henty

Oct. 30, 2011

view src

by jcid＠dillo.org

On Tue, Oct 25, 2011 at 08:50:08AM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 20, 2011 at 06:41:17PM +0000, corvid wrote: > > Jorge wrote: > > > A quick trick to avoid viewing source of the "view source" page. > > > A proper solution would be appreciatted. > > > > Does that break things, or do you just dislike it? > > I don't remember exactly what the problem was (man I'm getting old). > > There were two issues (AFAIR): > 1) avoiding "always reload" (through dpi even on Back/Fwd). > 2) avoid recursive URL expansion on reload. > > The current URL scheme helps with 2) and allows handling of > 1) in the canonical way. > > Please test the attached patch. So far I see no problem with it. Have you had any trouble with it? If not, I'd like to commit it. -- Cheers Jorge.-

Oct. 30, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {lleft, right}-tab

by obeythepenguin＠gmail.com

Jorge wrote: > > Jeremy Henty wrote: > > >> > Another case of "let's be like the other browsers". See: > > >> > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > ... yeah some term emulators default to Ctrl+{PgUp,PgDn} > It looks OK to me. > Comments? > -- Cheers > Jorge.- I don't have a problem with the patch, but I do question the reasoning. Dillo is a web browser, so most users will logically expect it to behave like other web browsers they have used. Following Chrome, for instance, is quite logical since it's a well-known browser many users are probably familiar with. On the other hand, most users *don't* expect Dillo to behave like a terminal emulator, which is a different kind of program entirely. It's the same thing as with the input box keys. At best it's mildly confusing, and if it conflicts with the expected behavior, it can cause a great deal of frustration. Frustration hurts usability and drives away potential users. So let's keep it if Chrome does it, but I wouldn't worry about Konsole and GNOME Terminal and Terminal.app and mxterm and aterm and GNU screen and whatever else people are using to run /bin/sh. If you really think Dillo should act like a Unix shell, you have your personal keysrc. Just my two cents, ~Benjamin

Oct. 30, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab

by corvid＠lavabit.com

Jorge wrote: > On Mon, Oct 24, 2011 at 10:35:02AM +0100, Jeremy Henty wrote: > > Jeremy Henty wrote: > > > > > > Another case of "let's be like the other browsers". See: > > > > > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > > ... yeah some term emulators default to Ctrl+{PgUp,PgDn} > > It looks OK to me. > Comments? *has no objection*

Oct. 29, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab

by jcid＠dillo.org

On Mon, Oct 24, 2011 at 10:35:02AM +0100, Jeremy Henty wrote: > > Bump! It's a simple patch that should be easy to review. > > > Jeremy Henty wrote: > > > > Another case of "let's be like the other browsers". See: > > > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… ... yeah some term emulators default to Ctrl+{PgUp,PgDn} It looks OK to me. Comments? -- Cheers Jorge.-

Oct. 29, 2011

Mailing list outage?

by onepoint＠starurchin.org

Johannes Hofmann wrote: > On Fri, Oct 28, 2011 at 03:41:37PM -0300, Jorge Arellano Cid wrote: > > On Fri, Oct 28, 2011 at 10:37:15AM +0100, Jeremy Henty wrote: > > > > > > Did the mailing lists go down this week? A message I sent on Monday > > > has only just appeared. > > > > > > It seems to be working OK now. > > > > Yes, dillo.org (website, mailing lists, dillo.org emails) was > > down at least for a full day. > > According to Andreas it seems to be a hardware issue. He's working > on it. Once again, many thanks to Andreas. Regards, Jeremy Henty

Oct. 28, 2011

Mailing list outage?

by Johannes.Hofmann＠gmx.de

On Fri, Oct 28, 2011 at 03:41:37PM -0300, Jorge Arellano Cid wrote: > On Fri, Oct 28, 2011 at 10:37:15AM +0100, Jeremy Henty wrote: > > > > Did the mailing lists go down this week? A message I sent on Monday > > has only just appeared. > > > > It seems to be working OK now. > > Yes, dillo.org (website, mailing lists, dillo.org emails) was > down at least for a full day. According to Andreas it seems to be a hardware issue. He's working on it. Cheers, Johannes

Oct. 28, 2011

Mailing list outage?

by jcid＠dillo.org

On Fri, Oct 28, 2011 at 10:37:15AM +0100, Jeremy Henty wrote: > > Did the mailing lists go down this week? A message I sent on Monday > has only just appeared. > > It seems to be working OK now. Yes, dillo.org (website, mailing lists, dillo.org emails) was down at least for a full day. -- Cheers Jorge.-

Oct. 28, 2011

Mailing list outage?

by onepoint＠starurchin.org

Did the mailing lists go down this week? A message I sent on Monday has only just appeared. It seems to be working OK now. Regards, Jeremy Henty

Oct. 28, 2011

suggest next page feature

by itsme_410＠yahoo.com

midori has a nice feature which really would be a nice addition to dillo. From the midori webpage: "Many people don't know about a nitfy feature in Midori, which is going Forward to the next page. From now on you can hit Space at the bottom of a page to go to the next page, just like in a mail client. Note that this depends on the page. Pages with links labelled "Next" or similar will be recognized. Ideally ?rel="next"? is used in the HTML so Midori knows what the next page is." It would be nice if dillo had it too, on low-end systems where using mouse is at a premium. Alternatively, can keybindings be made to mimic this (and similar features)? Many thanks, T

Oct. 27, 2011

[test]: Am I getting through?

by onepoint＠starurchin.org

Test, please ignore. I thought I emailed the list on Monday and nothing has appeared so I am just checking it still works for me. Regards, Jeremy Henty

Oct. 26, 2011

view src

by jcid＠dillo.org

On Thu, Oct 20, 2011 at 06:41:17PM +0000, corvid wrote: > Jorge wrote: > > A quick trick to avoid viewing source of the "view source" page. > > A proper solution would be appreciatted. > > Does that break things, or do you just dislike it? I don't remember exactly what the problem was (man I'm getting old). There were two issues (AFAIR): 1) avoiding "always reload" (through dpi even on Back/Fwd). 2) avoid recursive URL expansion on reload. The current URL scheme helps with 2) and allows handling of 1) in the canonical way. Please test the attached patch. So far I see no problem with it. In other words: maybe I forgot to re-enable it after solving the problem, or forgot what the problem was afterwards! -- Cheers Jorge.-

Oct. 25, 2011

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab

by onepoint＠starurchin.org

Bump! It's a simple patch that should be easy to review. Regards, Jeremy Henty Jeremy Henty wrote: > > Another case of "let's be like the other browsers". See: > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > > This will require an update to the help page on the web site. > > Congratulations on the keysrc code, it was very easy to understand and > modify. > > Next I was going to look at binding Ctrl-[1-8] to "go to the <n>-th > tab" and Ctrl-9 to "go to the rightmost tab" for the same reasons as > this patch - the other browsers do it. Comments? > > Regards, > > Jeremy Henty

Oct. 24, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

Hi Johannes, On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote: > [...] > Independent of this problem I think we should decide on the layering > of our base libraries (lout and dlib) to avoid code duplication. > My favorite option would be basing dlib on lout. > Any opinions? Historically: * the reason for using C++ (partly) in Dillo was FLTK (to be able to use its C++ API). * Sebastian and I worked independently (Dw/rest respectively) and ended with two libs. * This approach allowed for Dw and Dlib to be standalone. (thus helping Sebastian with other Dw projects and me/others to reuse Dlib in other pure C projects). Which is a good thing! One way to keep the advanges is to base lout on dlib. Mixing C/C++ for lout; this may be uglier/less-convenient than current status quo, so it would be a trade off. OTOH basing dlib on lout would force using C++ in pure C programs. :-P -- Cheers Jorge.-

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote: > On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote: > > > > Here's an idea of what we'd get: > > > > http://www.dillo.org/test/ascii_strcasecmp.diff > > > > - The naming is clear but kind of ugly. > > - I haven't added explanatory comments yet. > > - For the moment, it just #defines dStr(n)casecmp to the > > ASCII version because there are a bunch of them, but I'd > > go through and change the calls. > > > > Thoughts? > > I think it's nasty, but the right way to fix this. Yeah. Ater all locales/utf-8 is seldom a simple thing to handle right. If we'd have to: s/dStrcasecmp/dStrASCIIcasecmp/g s/dStrncasecmp/dStrnASCIIcasecmp/g then I'd keep the old function name and explain in the function's comment why it is restricted to, or handled in the new way. From a distance this global change looks to me like exposing ourselves to more troubles. In other words, why not: int dStrcasecmp(...) { if (locale has special rules) special treatment else strcasecmp(...) } Disclaimer: I haven't studied the problem in detail. -- Cheers Jorge.-

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > Did you find any cases where the localized version actually makes sense? I left the findtext code alone, since neither case will work well anyway. > Independent of this problem I think we should decide on the layering > of our base libraries (lout and dlib) to avoid code duplication. > My favorite option would be basing dlib on lout. > Any opinions? It would make sense. Speaking of lout, we still have #define prefs_show_msg 1 in lout/msg.h. Oh, and there's the BitSet/Bitvec duplication...

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote: > > Here's an idea of what we'd get: > > http://www.dillo.org/test/ascii_strcasecmp.diff > > - The naming is clear but kind of ugly. > - I haven't added explanatory comments yet. > - For the moment, it just #defines dStr(n)casecmp to the > ASCII version because there are a bunch of them, but I'd > go through and change the calls. > > Thoughts? I think it's nasty, but the right way to fix this. Did you find any cases where the localized version actually makes sense? Not sure how a lowercase roman 2 should look like in tr_TR :-) > > Skimming through the diff now, I'm noticing the cases like > if (dASCIItolower(attrbuf[0]) == 'j') > and thinking maybe > if (attrbuf[0] == 'j' || attrbuf[0] == 'J') > would be better, but then this issue is probably too tiny to waste > precious seconds of my life in noticing. I would guess that you end up with pretty much the same assembler code in both cases. > (Whereas continuing to use tolower() because we know that 'j' > is safe would be bad practice, in my opinion.) right. Independent of this problem I think we should decide on the layering of our base libraries (lout and dlib) to avoid code duplication. My favorite option would be basing dlib on lout. Any opinions? Cheers, Johannes

Oct. 23, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Here's an idea of what we'd get: http://www.dillo.org/test/ascii_strcasecmp.diff - The naming is clear but kind of ugly. - I haven't added explanatory comments yet. - For the moment, it just #defines dStr(n)casecmp to the ASCII version because there are a bunch of them, but I'd go through and change the calls. Thoughts? Skimming through the diff now, I'm noticing the cases like if (dASCIItolower(attrbuf[0]) == 'j') and thinking maybe if (attrbuf[0] == 'j' || attrbuf[0] == 'J') would be better, but then this issue is probably too tiny to waste precious seconds of my life in noticing. (Whereas continuing to use tolower() because we know that 'j' is safe would be bad practice, in my opinion.)

Oct. 23, 2011

use C locale for LC_CTYPE

by corvid＠lavabit.com

furaisanjin wrote: > Could you add locale setting on preference to make dillo use the > preference locale rather than default "C" at start up? I'll back out the change and look into handling this the usual way....

Oct. 23, 2011

use C locale for LC_CTYPE

by furaisanjin＠gmail.com

Hello corvid. I gave you wrong information. I don't explicitly set locale but implicitly set locale (probably through LANG but I'm not sure). locale command shows current my locale setting like these. LANG=ja_JP.eucJP LC_CTYPE="ja_JP.eucJP" LC_COLLATE="ja_JP.eucJP" LC_TIME="ja_JP.eucJP" LC_NUMERIC="ja_JP.eucJP" LC_MONETARY="ja_JP.eucJP" LC_MESSAGES="ja_JP.eucJP" LC_ALL= Your locale patch (c6cbf3ae7ffd) has side effect on my dillo and while converting to Kanji, font width is half and it's not easy to recognize. Could you add locale setting on preference to make dillo use the preference locale rather than default "C" at start up? Regards, furaisanjin

Oct. 22, 2011

Dillo on Cygwin/X

by obeythepenguin＠gmail.com

I should probably resist the bait here, but... Jorge wrote: > > Is there any interest to support this target on a source code basis? > I'd like to have a way to run dillo on Win*, but not sacrificing > current portability [2], nor having to write a completely different > code path for Win*. I'll just say patches 2, 6, 7, 8, 9, 11, and maybe 14 will get you 85% of that, without sacrificing *any* existing portability, and with only minimal changes to the existing Dillo code: http://dillo-win32.sourceforge.net/dillo/dillo3-patches.php Patches 7 and 8, the sockets abstraction layer, are the big ones; the rest of them are small tweaks. The remaining 29 patches are things like UI tweaks and moving DPIs back into the browser, which you are free to leave out. Oh, and I do regularly test my code on Unix, if you're wondering: http://obeythepenguin.users.sourceforge.net/openbsd/files/screenshot.png http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=unix-openb… > An API that works in both would be a good solution. For instance, > we know that some dpi servers already work in Win* (with cygwin). > There may even be a way to achieve it natively, and I seem to > recall the FLTK3 team had this in mind. It would be more than > worth to ask them about their plans on the subject. > Again, as I'm not a Win* developer, I don't qualify > to lead this effort on the Win* side. > HTH. Well, frankly I don't think most of the current DPIs belong outside the browser in the first place, as I've explained here: http://dillo-win32.sourceforge.net/dillo/dpi.php (If I have any technical details about the implementation wrong, please let me know.) I have started work on a native Windows DPI patch if you'd like to see it, though I'm afraid it's not functional yet, and it's *very* ugly code. Regards, ~Benjamin

Oct. 22, 2011

Address bar keys (bug #1012)

by obeythepenguin＠gmail.com

Rogutes wrote: > Benjamin Johnson (2011-10-21 00:03): > > >> >Having it consistent over all text inputs and configurable > > >via> >keysrc sounds reasonable to me. I don't know the keysrc > > >details> >though, so I might miss something.> >Cheers,> > > >>JohannesHaving input/insert mode and macros in keysrc would be > > >interesting, if nottoo complex. > Look how indecipherable your quotations are. Sorry about that. My mail client (Opera Mail) seems to mangle things from time to time, but frankly I'm not too sure why. > Other than that, I have to agree with most points, because you seem to > have done more homework than I have. I lose sleep over this sort of thing. It's the little things that make or break a user interface; big problems aren't as bad, because if they're obvious enough you can learn to work around them. (Not that I mean that to imply anything about Dillo's UI!) > Shift-{Left,Right} doesn't do anything here and I would expect it to > select text [I guess conventionally]. > Ctrl-A selects all text in other FLTK apps, so dillo must have most > input > boxes covered with the CustInput class. > ---- Rogut?s Sparnuotos Looking through the code, there appear to be three(!) different classes: - CustInput in src/ui.cc - CustInput2 in src/dialog.cc - CustInput3 in dw/fltkui.cc Thanks for mentioning that -- I hadn't noticed the other two. Somehow, it seems just a little excessive... ~Benjamin

Oct. 22, 2011

mailing list trivia (Re: [REPOST] Re: Dillo Win32

by rogerx.oss＠gmail.com

Thoughts) Reply-To: In-Reply-To: <20111021073336.GA12742 at local> > On Fri, Oct 21, 2011 at 07:33:36AM +0000, corvid wrote: > >I see what the problem was now with the strange little chunk of a msg. >When Roger wrote: >> [...] >> required either. >> >> From here, mintty's code is likely an excellent resource to figure how they >> worked around the Window's issues with mouse copy & pasting. > >Pipermail saw a blank line followed by "From ", and thought "new msg!" and >got all confused when generating the archive. IIRC, mail(1) always had a hard >time with that one as well. This is explicitly Google's fault then. I use mutt with gmail, and I find GMail likes blank lines on copy & paste. There might be something within my muttrc causing this too, but I doubt it as I never seen so many problems with blank lines and extended long lines after pasting within a Mutt session. (Only using Mutt with GMail IMAP have I seen this! Never in an ordinary local Mutt session. I also use VIM as the editor: set editor = '/usr/bin/vim --noplugin +/^$' # default: '(empty)' I think it happens during the IMAP session, IMAP/terminal are interpretting newlines incorrectly on paste. As to why this occurred within the From: field makes this even more strange as copy/paste would likely not have occurred there. Personally, I consider this a GMail bug. -- Roger http://rogerx.freeshell.org/

Oct. 21, 2011

use C locale for LC_CTYPE

by corvid＠lavabit.com

Jorge wrote: > FWIW, I don't remember the details but it seems to me that long ago > we had a thread on the problems of changing the locale set by the user. *has a look through the archives* What I could find was: - In downloads dpi, having to set C locale in the environment before exec()ing wget in order to parse the log correctly. - Dillo resetting to C locale for gtk cmdline option parsing. - Temporarily resetting LC_NUMERIC to C locale for prefs parsing. I don't believe LC_NUMERIC is currently set in the fltk-1.3 era, although it might be good to reset in general because of the strtod() in Html_parse_length_or_multi_length().

Oct. 21, 2011