- Dillo-dev - lists.mailman3.com

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