From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: mac/dos/unix newline conversion without specify from Date: Fri, 07 Dec 2007 17:35:13 -0500 Message-ID: References: <9fce01a5-ed79-4981-8b02-29e335b694cd@d21g2000prf.googlegroups.com> <168cd816-9fd4-49e8-a2a6-fe2ff6cf69a0@s36g2000prg.googlegroups.com> <85zlwptc5l.fsf@lola.goethe.zz> <17f871e1-56be-4269-8e44-9fb2652b02f6@a35g2000prf.googlegroups.com> <85prxlt8g0.fsf@lola.goethe.zz> <1eb0de3a-9c0f-4488-b05a-1ef36df87871@d4g2000prg.googlegroups.com> <85hcixt6ld.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1197067331 19939 80.91.229.12 (7 Dec 2007 22:42:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2007 22:42:11 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Dec 07 23:42:20 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 1J0lth-00028l-47 for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Dec 2007 23:42:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0ltQ-0005CP-4t for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Dec 2007 17:42:00 -0500 Original-Path: shelby.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.umontreal.ca!news.umontreal.ca.POSTED!not-for-mail Original-NNTP-Posting-Date: Fri, 07 Dec 2007 16:35:13 -0600 Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:PbBWjsip/FxzAImho/rmxA5HYVw= Original-Lines: 34 X-Usenet-Provider: http://www.giganews.com Original-NNTP-Posting-Host: 132.204.27.213 Original-X-Trace: sv3-btw69Q6GE5f+pvZbOo2Sp7pg30hMfp5cV/AInJkhyp+jYOhEMDKI5tzQ9HnNRt3suvv7i20mXMvOsVf!CfB+2rqOJSzG7rOFG7EwyCDSh95doAGGsurxAe/SUsv/GUfXy4oruacNN/rZ//CHwj27gHuv+sDb!c2VF8VlcW0Par0q1/A== Original-X-Complaints-To: abuse@umontreal.ca X-DMCA-Complaints-To: abuse@umontreal.ca X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.36 Original-Xref: shelby.stanford.edu gnu.emacs.help:154502 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:49931 Archived-At: > <> > Thanks for finding the cause. That's probably not the cause of your original problem. It's the cause of the problem you saw when you tried the replace-string thingy to replace "all" CRs into LFs. If you used the C-x RET f mac RET method I suggested earlier to convert unix-style files to mac-style files, this problem shouldn't appear. > Anyhow, for what's worth, i think this is still something emacs (in > particular Mac versions) should fixup. Basically, the scenario is that > a user opens mac classic html files, work on it, save it, then next > time he opens the files shows ^M. (this actually happens to me a lot That's a clear bug, indeed. But I can guarantee that it normally works, so please give us more details so we can track down the problem. The only know case where a Mac file is misidentified is if it contains LF chars, which shouldn't happen in normal circumstances. > since i work on a server with non-professional coders and they use > BBEdit that is still set to CR as newline) In contrast, i open the > same file (with CR as eol but a LF at the end) in Xcode, TextWrangler, > TextEdit, all opens correctly and indicate as Mac files. The final LF is clearly an error in the file. You need to track down its origin. > * perhaps require-final-newline should insert the right EOL char based > on the encoding. It does. Stefan