Date: Thu, 17 Feb 2000 13:40:47 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Esa A E Peuha cc: djgpp AT delorie DOT com Subject: Re: Problems with Emacs 20.5 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.