pan-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gtkspell-devel] Re: [Pan-devel] pan, gtkspell, and specifying your


From: Charles Kerr
Subject: Re: [Gtkspell-devel] Re: [Pan-devel] pan, gtkspell, and specifying your language
Date: Fri, 2 Aug 2002 11:23:42 -0700
User-agent: Mutt/1.3.20i

>> It's great to hear from you!  I was about to contact you this morning...
> Ah, good, you're the one I wanted to talk to.
Hi. :)

> Here's the point I was trying to make-- I clearly wasn't clear enough 
> about it before because nobody but me saw it:
> To keep binary compatibility with the older gtkspell, I can't introduce 
> new functionality without doing some hacks (for example, it'd be nice to 
> specify the language and encoding to gtkspell_attach to allow per-view 
> lang/charset, but that changes the API).  So I was looking for advice in 
> two separate ways:
>  - what can be changed without breaking backward compat (2.0.x)
>  - what needs to be changed for the future (2.1.x)
> Realistically, this means that 2.1 will probably happen after the new 
> releases mentioned below.

Introducing new functions shouldn't break backwards compatability.
So adding gtk_spell_attach_language (GtkTextView*, language) wouldn't harm
anyone so long as gtk_spell_attach (GtkTextView*) still existed.

(In fact, gtk_spell_attach() would probably be implemented as a wrapper
around gtk_spell_attach_language, passing the default language as the
second argument.)

> But this mention of character sets is interesting-- how are you putting 
> non-UTF8 data in a GtkTextView without Gtk complaining?

We're not.  It's all UTF-8 inside of the textview, then it's
iconv()ed to the user's preferred charset when posting.
(Or at least that's what will do when I fix 0.12.92's bug. ;)

>> More urgently, though, I've also got a handful of crasher bug
>> reports that are best handled in gtkspell.   My (unrealistic?) wish
>> would be to have these fixes in 2.0.1, punting configurable languages
>> to 2.0.2 if necessary, in the next 7-10 days so that Pan 0.13.0 with
>> gtkspell can be released in time for bundling with the new RH and
>> Mandrake releases.
>>
>>These are all GtkSpell-related crashes in Pan:
>>* http://bugzilla.gnome.org/show_bug.cgi?id=89657
>>* http://bugzilla.gnome.org/show_bug.cgi?id=89588
>>* http://bugzilla.gnome.org/show_bug.cgi?id=88924
>>* http://mail.freesoftware.fsf.org/pipermail/pan-users/2002-July/001500.html
> 
> What are these "exceptions" you speak of?  I am a C programmer. :P

http://mail.freesoftware.fsf.org/pipermail/pan-users/2002-July/001500.html
and http://bugzilla.gnome.org/show_bug.cgi?id=89657 are both cases of aspell
throwing an exception that nobody's catching, which causes Pan to crash.

I would file this as a bug report to aspell, but it appears that aspell
is both (a) no longer being maintained and (b) being rewritten, with the
new version in a "pre-alpha" state (http://aspell.sourceforge.net/).

Not sure what to do about this.

> Hm, that's interesting.  You rebuid the entire text view, but GtkSpell 
> doesn't affect it?  GtkSpell just attaches to the insert-text signal 
> (among others), both before and after it runs, and uses the difference 
> between the insertion point across that operation to see what has changed.

I haven't looked into this, I'm just passing along what a user reported.
The user could be smoking crack. :)

> Anyway, I'll investigate those bugs and just drop the language stuff 
> until it can be done properly.

Cool.

> I'll try to restrict discussing further development to the 
> gtkspell-devel mailing list, too, so feel free to sign up or read the 
> archives.

For pan-devel people interested:
http://lists.sourceforge.net/lists/listinfo/gtkspell-devel (gtkspell signup)
http://www.geocrawler.com/redir-sf.php3?list=gtkspell-devel (gtkspell archives)
http://mail.gnu.org/mailman/listinfo/aspell-devel (aspell signup)
http://mail.gnu.org/pipermail/aspell-devel/ (aspell archives)

cheers,
Charles



reply via email to

[Prev in Thread] Current Thread [Next in Thread]