Re: [PATCH] Unicode Lisp reader escapes

[Kim F. Storm]

Oliver Scholz <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
>
>> Oliver Scholz <address@hidden> writes:
>>
>>> We are discussing a *very* special case here; it affects only Emacs
>>> Lisp source files, because compilation of those, so to say, "freezes"
>>> the particular settings for unification/fragmentation in the *.elc
>>> file.
>>
>> I really wonder why this has suddenly become such a big issue.
>>
>> In practice, these things have worked fine for ages, so why bother _now_
>> when we should focus on finalizing the release of 22.1 ?
>
> Unification and UCS fragmentation are new in Emacs 22.

But Emacs 22 already has a large user community, and I don't
recall anyone actually complaining about it!

>
> [...]
>> I would suggest to leave the entire issue for after the release!
>
> I agree, in principle. IIRC, I was the first one here to suggest to
> just document the issue and be done with it. But documenting it would
> be a good idea. 

Indeed.

>                 Something along the lines: "When using non-ASCII
> characters in Emacs Lisp source files, beware that compilation
> "freezes" some of your current settings for character unification
> and/or fragmentation. This might exactly be what you want. But if you
> compile Emacs Lisp files with the intention to give the compiled files
> to other users, you should make sure that the following settings are
> at their default value: ..."

Is this a problem for any of the lisp files included in CVS emacs ??

Then it could be a problem wrt distribution pre-built versions.

Otherwise, I still think it is better left alone -- and documented
as you suggested (or simply advise against distributing such files
to anybody and let them compile the files themselves).

Could the byte-compiler warn if it encounters a non-ascii character
that may cause problems?

-- 
Kim F. Storm <address@hidden> http://www.cua.dk