Mail Archives: djgpp/2000/02/17/16:16:55
On Thu, 17 Feb 2000, Esa A E Peuha wrote:
> I guess I should have read the manual more carefully.
I cannot judge that ;-). But this issue (as all the rest that pertains
to multi-lingual support in Emacs) is very tricky, so I'm not sure you
could be blamed, no matter how much did you read the manual.
> So I figured, but it still seems rather counter-intuitive to me. The
> natural way to implement `C-x 8' would seem to be that it directly
> generates codes in the internal representation, but I suppose there's
> a reason why it wasn't implemented that way.
Yes, there is a reason: if `C-x 8' would generate the internal multibyte
representation, it would not work in unibyte buffers, or when Emacs is
invoked with the --unibyte command-line option.
> However, couldn't `C-x 8'
> change the keyboard coding system temporarily while feeding the character?
This would prevent it from being useful with other Latin-N characters.
While currently `C-x 8' supports Latin-1 only, it could (and should) be
easily extended to support Latin-2, Latin-3, etc.
I'm also not sure that there's only one ``right'' keyboard coding system
for this. I will look into that.
In any case, I really think that input methods is a better way to input
non-ASCII characters. You type the same keys as with `C-x 8', but unlike
the keyboard coding system, input methods are buffer-specific and there
are more of them to choose from.
> Because 437 is the codepage that is in my video card's ROM (and probably
> in the ROMs of a great majority of video cards). I'm not willing to waste
> any DOS memory for cp850 as I don't need it. Of course, that doesn't stop
> DOS from incorrectly reporting the current codepage as 850...
I assume you saw in the manual the explanation of how to fix this inside
your _emacs init file.
- Raw text -