Re: windows-1251 language environment

[Kenichi Handa]

In article <address@hidden>, Dave Love <address@hidden> writes:

> Kenichi Handa <address@hidden> writes:
>>  At first, I have installed a mechanism of auto-loading a
>>  coding system.

> Is it really worth it for the 8-bit sets?  I'm not sure whether to
> think this is significant or not:

> let ((stats (garbage-collect)))
>   (load "code-pages")
>   (pp (list stats (garbage-collect))))

It's not easy to see the effect of preloading code-pages
from this output.   But, when I put this in loadup.el
        (load "international/code-pages")
the resulting Emacs is 585K-byte bigger.   I think we can't
ignore this size.

>>  I have not yet tested it fully.  We may have to add GCPROs
>>  in several places.

> <URL:ftp://dlpx1.dl.ac.uk/fx/emacs/Mule/autoload-coding-systems.diff>
> was reasonably well tested, probably also on a system where gcpro was
> relevant then (though I don't know if I tested it by forcing GC during
> loading).

Stefan also showed me his implementation.  I reached my code
because I didn't want to change anything other than the
place related to coding-system.  That is because this
mechanism is obsolte in emacs-unicode in which defining a
coding system is so cheap that there's no need of this
mechanism.

>>  Right.  I think what we need for language environment is a
>>  mechanism similar to face; i.e. creating a new one easily
>>  while allowing inheriting, and customizing an existing one
>>  easily.

> I did something about customizing the language alist some time ago.
> As far as I remember, it naturally used the mechanism for overriding
> elements of the standard value in customized lists, and that interface
> was vetoed for reasons I didn't understand.  Presumably inheritance
> would use a similar mechanism, but I'm not sure how useful it is.

> As it is, a language environment has to cover several things that
> should be orthogonal:

>  * The language (which might influence input methods as well as the
>    default Ispell dictionary, at least);

>  * The charset/coding system preferences (which might also influence
>    input methods, though the hooks now in Quail make that less of an
>    issue);

>  * Other things that currently aren't dealt with properly, like paper
>    size (for ps-print), calendar holidays &c (which may depend on the
>    locale territory, not just the language).

>>  For instance, in such a case, we can allow people to create
>>  a new lang. env. by inheriting, for instance, Russian, and
>>  modifying coding-system to windows-1251.

> Is this actually better than allowing them to specify (the equivalent
> of) the locale ru_RU.windows-1251?

If that locale is available to a user, that is ok.
Otherwise, there should be a way to provide the same
environment to him.

---
Ken'ichi HANDA
address@hidden