emacs-devel
[Top][All Lists]
Advanced

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

Re: Syncing Gnus and Emacs repositories


From: Kenichi Handa
Subject: Re: Syncing Gnus and Emacs repositories
Date: Tue, 19 Jun 2007 11:19:59 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.0 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> >  > So in that case, making such changes in the Unicode branch directly,
> >  > as I suggested, would be a good way of installing changes without
> >  > interfering with the future merge, right?
> > 
> > Assuming that those making changes in the Unicode branch are
> > thoroughly familiar with it, yes.

> Are you sure such a thorough familiarity is indeed required?  AFAIK,
> most of the radical changes in the Unicode branch are fairly
> low-level; the changes to application-level APIs are relatively minor
> and matter in marginal cases.  E.g., most Lisp programs should not
> care about the internal representation of characters in buffers and
> strings.  Emacs 22 already unifies Latin and various other scripts in
> a way that, at least on the outside, closely resembles Unicode-based
> representation of characters.

> Handa-san, can you comment on this?

What you wrote in the above paragraph is almost right.

But, fairly big programs (especially gnus, and the other
mail tools) have to pay attention to characters decoding and
encoding, and almost all workarounds for the Emacs 22's
legacy charset/code-point model get wrong (or unnecessary)
for emacs-unicode.  Some of already existing workarounds may
have bugs (or shortages).  More the merging delays, the
possibility of people spending their time for fixing them in
vain gets higher.  In addition, such a fix in the trunk
tends to cause confliction when merged into emacs-unicode-2
branch.

---
Kenichi Handa
address@hidden




reply via email to

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