From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: changing encoding of buffer Date: Mon, 28 May 2007 23:21:34 +0300 Message-ID: References: <7rnqi4-vn5.ln1@ID-306968.user.individual.net> NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1180383740 6323 80.91.229.12 (28 May 2007 20:22:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 May 2007 20:22:20 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 28 22:22:19 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HsljK-0001uF-Pl for geh-help-gnu-emacs@m.gmane.org; Mon, 28 May 2007 22:22:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HsljK-00040u-9S for geh-help-gnu-emacs@m.gmane.org; Mon, 28 May 2007 16:22:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hslj7-00040p-Ec for help-gnu-emacs@gnu.org; Mon, 28 May 2007 16:22:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hslj4-00040d-Ua for help-gnu-emacs@gnu.org; Mon, 28 May 2007 16:22:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hslj4-00040a-Q0 for help-gnu-emacs@gnu.org; Mon, 28 May 2007 16:21:58 -0400 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hslj4-0005CY-Ar for help-gnu-emacs@gnu.org; Mon, 28 May 2007 16:21:58 -0400 Original-Received: from HOME-C4E4A596F7 ([81.5.56.70]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id HXZ64895 (AUTH halo1); Mon, 28 May 2007 23:21:37 +0300 (IDT) In-reply-to: <7rnqi4-vn5.ln1@ID-306968.user.individual.net> (message from M G Berberich on Mon, 28 May 2007 12:34:47 +0200) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:44513 Archived-At: > From: M G Berberich > Date: Mon, 28 May 2007 12:34:47 +0200 > > When I reply, my newsreader appends my UTF-8 signature and starts > emacs. If you append UTF-8 text unconditionally, I think you are guilty no less than MS: no one said that arbitrary encoded text can be freely mixed with UTF-8. Suppose those unnamed "MS-products" did announce they produce text in windows-1252, how would that help you avoid the problem? > I wrote this function to solve the problem: > > (defun fix-ms-posting () > "Fixes newsposting that are garbled up by Microsoft-Software" > (interactive) > (let ((coding-system-for-write 'raw-text) > (coding-system-for-read 'utf-8) > (end (progn (end-of-buffer) (search-backward "\n-- \n")))) > (revert-buffer-with-coding-system 'utf-8) > (set-buffer-file-coding-system 'utf-8) > (shell-command-on-region (point-min) end > "recode windows-1252..utf-8" nil t))) I see no need to call `recode': Emacs can do that itself. > - Is there realy no other way to change the encoding of the buffer > than doing a revert? Can't this be done in-place? No, it cannot be done in-place, because by the time you look at the text in the buffer, it was already converted (a.k.a. "decoded") from the external encoding on the disk file to the internal representation Emacs uses in buffers and strings. The original byte stream is gone, vanished without a trace. > - revert-buffer-with-coding-system always ask if it should do so, can > this be switched off? Currently, the only practical way is to define a revert-buffer-function that simply invokes revert-buffer with its NOCONFIRM arg non-nil. (Don't forget to unbind revert-buffer-function before calling revert-buffer, to avoid infinite recursion!) > - I moved the search-backward to the variables list of let to make it > fail before harm is done if there is no signature. Is this the way > to do it? Sorry, I don't understand what you want to do, and why is that a problem.