Gnus changes in Emacs-Unicode branch

Gnus changes in Emacs-Unicode branch

[Kai Großjohann]

Dave is doing some changes in the Gnus that's included Emacs-Unicode
branch.  I wonder if somebody is following this and incorporating the
changes into Oort?

No, I'm not volunteering :-(

Thesis, thesis.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Gnus changes in Emacs-Unicode branch

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Dave is doing some changes in the Gnus that's included Emacs-Unicode
> branch.  I wonder if somebody is following this and incorporating the
> changes into Oort?

It has never been clear to me what the goal, timeline, backing, etc
the Emacs Unicode branch has.  Will it be usable for beta testers
soon?  Is it guaranteed to be the future emacs core, or is it just
hacking to learn how it can be done?  I guess what I'm really asking
is that if it might be a waste of time to backport the changes.

Dave, would it make sense to do the unicode work on Oort instead of
5.9.0?  I'd assume Oort is ready for release whenever Emacs 22
releases.  I can think of at least one unicode related feature present
in Oort not present in 5.9.0; support for the new usefor UTF-8
headers.  If this path is chosen, it would mean that your code cannot
simply assume it is running in a unicode emacs, but will have to check
for this as it should work on (X)Emacs 20+ too, though.

Re: Gnus changes in Emacs-Unicode branch

[Dave Love]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I wonder if somebody is following this and incorporating the
> changes into Oort?

I hope not, unless they're finishing it off and testing it; in which
case, please tell me.

Re: Gnus changes in Emacs-Unicode branch

[Dave Love]

Simon Josefsson <jas@extundo.com> writes:

> I can think of at least one unicode related feature present
> in Oort not present in 5.9.0; support for the new usefor UTF-8
> headers.

I don't know what that means, but I _hope_ it has nothing to do with
the Emacs internal encoding.

> If this path is chosen, it would mean that your code cannot
> simply assume it is running in a unicode emacs,

I have tried to _eliminate_ assumptions in the MIME code about what
it's running in.  There's little reason for the code to care about the
internal encoding, despite how it was written.

[This applies to Emacs.  As far as I can tell, XEmacs Mule lacks the
necessary machinery to do things properly.]

Re: Gnus changes in Emacs-Unicode branch

[Simon Josefsson]

Dave Love <d.love@dl.ac.uk> writes:

>> I can think of at least one unicode related feature present
>> in Oort not present in 5.9.0; support for the new usefor UTF-8
>> headers.
>
> I don't know what that means, but I _hope_ it has nothing to do with
> the Emacs internal encoding.

It shouldn't, but I haven't verified it.

>> If this path is chosen, it would mean that your code cannot
>> simply assume it is running in a unicode emacs,
>
> I have tried to _eliminate_ assumptions in the MIME code about what
> it's running in.  There's little reason for the code to care about the
> internal encoding, despite how it was written.

That is good, I think.

> [This applies to Emacs.  As far as I can tell, XEmacs Mule lacks the
> necessary machinery to do things properly.]

It shouldn't be worse than it is today, which seems to be enough for
many people.

Re: Gnus changes in Emacs-Unicode branch

[Dave Love]

Simon Josefsson <jas@extundo.com> writes:

> > I don't know what that means, but I _hope_ it has nothing to do with
> > the Emacs internal encoding.
> 
> It shouldn't, but I haven't verified it.

Then I don't understand the issue.  [Why is something utf-8 specific
anyhow?  There shouldn't be anything special abut utf-8, which has
been a problem with Gnus code before.]

> > I have tried to _eliminate_ assumptions in the MIME code about what
> > it's running in.  There's little reason for the code to care about the
> > internal encoding, despite how it was written.
> 
> That is good, I think.

If it gets accepted...

> > [This applies to Emacs.  As far as I can tell, XEmacs Mule lacks the
> > necessary machinery to do things properly.]
> 
> It shouldn't be worse than it is today,

I don't understand.  I'm talking about today (or maybe yesterday --
Debian Woody).

> which seems to be enough for many people.

Perhaps they have low expectations and/or there aren't many using it
in anger.

Re: Gnus changes in Emacs-Unicode branch

[Simon Josefsson]

Dave Love <d.love@dl.ac.uk> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> > I don't know what that means, but I _hope_ it has nothing to do with
>> > the Emacs internal encoding.
>> 
>> It shouldn't, but I haven't verified it.
>
> Then I don't understand the issue.  [Why is something utf-8 specific
> anyhow?  There shouldn't be anything special abut utf-8, which has
> been a problem with Gnus code before.]

USEFOR says to use UTF-8, so Gnus tries to decode group names as
UTF-8.  Configurable depending on hierarchy and method, of course.  If
the way Gnus achieves this depends on the internal Emacs encoding, I
couldn't tell.

>> > [This applies to Emacs.  As far as I can tell, XEmacs Mule lacks the
>> > necessary machinery to do things properly.]
>> 
>> It shouldn't be worse than it is today,
>
> I don't understand.  I'm talking about today (or maybe yesterday --
> Debian Woody).

Err, OK, I thought this was related to the Emacs Unicode branch only.
If the patch is against Oort and todays' (X)Emacs, and FWIW, I'd vote
for simply installing it.

Re: Gnus changes in Emacs-Unicode branch

[Dave Love]

Simon Josefsson <jas@extundo.com> writes:

> USEFOR says to use UTF-8, so Gnus tries to decode group names as
> UTF-8.

OK, then there should be no issue in Emacs 21 iff the unicodes are
representable.  Otherwise (for most of the CJK space and anything
outside the BMP) the byte sequences will be maintained as eight-bit
chars, which may or mat not be a problem.

> Err, OK, I thought this was related to the Emacs Unicode branch
> only.

That's all I've touched.  I just qualified what I said about
implementation to exclude XEmacs.

> If the patch is against Oort and todays' (X)Emacs, and FWIW, I'd vote
> for simply installing it.

There is no patch as far as I know.  As I said, what I did hasn't been
finished or properly tested.