- Dillo-dev - lists.mailman3.com

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