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

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