contrib/ucs-tables.el obsolete for Emacs 21.3

contrib/ucs-tables.el obsolete for Emacs 21.3

[Reiner Steib]

Hi,

Emacs 21.3 (and Emacs' CVS HEAD) comes with `ucs-tables.el'.  It might
cause problems if a user adds `.../gnus/contrib' to `load-path'.

Therefore, I guess we should remove `contrib/ucs-tables.el'.
Additionally, `ucs-tables.el' without using a newer version of
`utf-8.el' (replacing the pre-dumped code) isn't so useful in Emacs
21.[1-2].  See the commentary section of `rs-gnus-unify.el'[*] for
more explanations.

Opinions?

Bye, Reiner.

[*] <URL:http://my.gnus.org/Members/rsteib/howto_unify/> or
<URL:http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/rs-gnus-unify.el>
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On 7 mai 2003, Reiner Steib stated:

>  Hi,

Hi,
  
>  Emacs 21.3 (and Emacs' CVS HEAD) comes with `ucs-tables.el'.  It
>  might cause problems if a user adds `.../gnus/contrib' to
>  `load-path'.

Yep.
  
>  Therefore, I guess we should remove `contrib/ucs-tables.el'.
>  Additionally, `ucs-tables.el' without using a newer version of
>  `utf-8.el' (replacing the pre-dumped code) isn't so useful in Emacs
>  21.[1-2].  See the commentary section of `rs-gnus-unify.el'[*] for
>  more explanations.
>  
>  Opinions?

I fully agree with you, just do it.

zeDek
-- 
http://www.gnusfr.org -- French Gnus user site

Anti-war disclaimer:
	"Bombing for peace is like fucking for virginity"

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Kai Großjohann]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Emacs 21.3 (and Emacs' CVS HEAD) comes with `ucs-tables.el'.  It might
> cause problems if a user adds `.../gnus/contrib' to `load-path'.
>
> Therefore, I guess we should remove `contrib/ucs-tables.el'.

I don't think so: what about people using Gnus on older versions of
Emacs?  ucs-tables.el was put there for older versions, after all.

Maybe the documented treatment of the contrib directory should be
different.  I think it's too simplistic to just add it to load-path.
Maybe we should tell people to take the files they need and copy them
to site-lisp or something.

WDYT?
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Ted Zlatanov]

On Thu, 08 May 2003, kai.grossjohann@gmx.net wrote:
> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
> 
>> Emacs 21.3 (and Emacs' CVS HEAD) comes with `ucs-tables.el'.  It
>> might cause problems if a user adds `.../gnus/contrib' to
>> `load-path'.
>>
>> Therefore, I guess we should remove `contrib/ucs-tables.el'.
> 
> I don't think so: what about people using Gnus on older versions of
> Emacs?  ucs-tables.el was put there for older versions, after all.
> 
> Maybe the documented treatment of the contrib directory should be
> different.  I think it's too simplistic to just add it to load-path.
> Maybe we should tell people to take the files they need and copy
> them to site-lisp or something.

Maybe contrib/ucs-tables.el should throw an error if emacs-version is
21.3 or greater?  The user could set gnus-load-contrib-ucs-tables if
they really, really want to use contrib/ucs-tables.el.

Another option is to rename it to ucs-tables-compat.el and make sure
nothing in it conflicts with the new ucs-tables.el.

Ted

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Kai Großjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Maybe contrib/ucs-tables.el should throw an error if emacs-version is
> 21.3 or greater?

That's a good idea.

I wonder what's the best utf-8.el to use with older Emacsen.  The one
in Emacs 21.3?
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Dave Love]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Additionally, `ucs-tables.el' without using a newer version of
> `utf-8.el' (replacing the pre-dumped code) isn't so useful in Emacs
> 21.[1-2].

I disagree.  It precisely solves the unification issue that people
continually complained about (and normally claimed was impossible to
solve).  I'm currently using it in Emacs 21.2.

(car (find-coding-systems-string 
      (string (make-char 'latin-iso8859-1 255)
	      (make-char 'latin-iso8859-15 255))))
  => iso-latin-1

> See the commentary section of `rs-gnus-unify.el'[*] for
> more explanations.
>
> Opinions?

Without wishing to sound rude:

 * If the documentation is unclear, or there are problems with the
   code, it would be nice to get bug reports.  It may well be
   difficult to use, but I'm not sure how -- it's just loading one or
   two compiled files.

 * What's wrong with the version I've distributed, which is what I
   actually use in 21.2?

 * The suggestion to modify iso-2022-7bit is a bad one, as handa says.
   I've also told people they probably don't want to unify on decoding
   generally, especially if they're working on Emacs code, and I don't
   understand why they do it anyway.  I purposely didn't suggest using
   a modified iso-2022 systems because it isn't harmless.

 * I don't know about this `latin-unity' thing, but XEmacs can't do
   the same -- it simply doesn't have the necessary facilities.

Things like that file which will clash with future versions should be
installed in the version-specific site-lisp directory, which is what
it's there for.  Have people been recommending something else?

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Kai Großjohann]

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

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> Additionally, `ucs-tables.el' without using a newer version of
>> `utf-8.el' (replacing the pre-dumped code) isn't so useful in Emacs
>> 21.[1-2].
>
> I disagree.  It precisely solves the unification issue that people
> continually complained about (and normally claimed was impossible to
> solve).  I'm currently using it in Emacs 21.2.

Didn't you say previously that ucs-tables.el would benefit from an
improved utf-8.el?  But thay may have been with 21.1, and the
utf-8.el in 21.2 might include the necessary facilities already.

I'm slightly confused now.

> Without wishing to sound rude:
>
>  * If the documentation is unclear, or there are problems with the
>    code, it would be nice to get bug reports.  It may well be
>    difficult to use, but I'm not sure how -- it's just loading one or
>    two compiled files.

The version that's now in the Gnus contrib directory has
unify-8859-on-{de,en}coding-mode which need to be called.

A short installation section mentioning this might be nice.  It would
be just two lines.

>  * What's wrong with the version I've distributed, which is what I
>    actually use in 21.2?

The problem is that people aren't using that version.  They are using
other versions.

If the version that's now in Gnus' contrib directory is not the one
you distributed, it would be really great if you could give it to us
again.  It was probably me who goofed up and got the wrong file,
somehow.  I apologize.

>  * I don't know about this `latin-unity' thing, but XEmacs can't do
>    the same -- it simply doesn't have the necessary facilities.
>
> Things like that file which will clash with future versions should be
> installed in the version-specific site-lisp directory, which is what
> it's there for.  Have people been recommending something else?

Yes.  There was a recommendation to add the Gnus contrib directory to
load-path.  Or even to move the files to the Gnus lisp directory.

It's the wrong approach.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Dave Love]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Maybe contrib/ucs-tables.el should throw an error if emacs-version is
> 21.3 or greater?

I don't think that's a good thing to do.  It just needs to be put in
the right place.

> The user could set gnus-load-contrib-ucs-tables if they really,
> really want to use contrib/ucs-tables.el.

??

> Another option is to rename it to ucs-tables-compat.el and make sure
> nothing in it conflicts with the new ucs-tables.el.

No.  That would screw require/provide.  The major incompatibility in
that file will be related to the removal of the
`char-coding-system-table' machinery recently, but also handa did
various sanitizations that were possible when it was actually part of
Emacs.

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Dave Love]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Didn't you say previously that ucs-tables.el would benefit from an
> improved utf-8.el?

I hope not.  ucs-tables provides tables that the utf-8 coding systems
(and others) use, not vice versa.

> The version that's now in the Gnus contrib directory has
> unify-8859-on-{de,en}coding-mode which need to be called.

Yes, but that's a feature.  Loading the file shouldn't invoke them.

> If the version that's now in Gnus' contrib directory is not the one
> you distributed,

I don't know what it is -- I haven't checked.  I was commenting on the
web page referenced and I didn't understand the recommendation to get
a version out of Emacs CVS specifically.

> Yes.  There was a recommendation to add the Gnus contrib directory to
> load-path.  Or even to move the files to the Gnus lisp directory.
>
> It's the wrong approach.

Perhaps someone could correct that if it's in the doc or add such
instructions for using anything that might appear in future Emacs
versions.  (I know that's difficult to tell in some cases, like
ucs-tables, so it's best to play safe.)

Re: contrib/ucs-tables.el obsolete for Emacs 21.3

[Kai Großjohann]

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

> Perhaps someone could correct that if it's in the doc or add such
> instructions for using anything that might appear in future Emacs
> versions.  (I know that's difficult to tell in some cases, like
> ucs-tables, so it's best to play safe.)

I've now added some stuff to contrib/README that tries to explain.  I
also added some explanations there why the files were added in the
first place.  I don't know for all of them.

Anyone who knows what to add, please do so.
-- 
This line is not blank.