GNU bug report logs - #4816
change of coding system without inquiry

Previous Next

Package: emacs;

Reported by: eisinger <at> informatik.uni-muenchen.de

Date: Tue, 27 Oct 2009 23:10:05 UTC

Severity: minor

Tags: patch

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 4816 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: eisinger <at> informatik.uni-muenchen.de
Cc: 4816 <at> debbugs.gnu.org
Subject: Re: bug#4816: change of coding system without inquiry
Date: Fri, 30 Oct 2009 11:02:49 -0400
> Our computer environment has for years been a SuSE distribution
> of Linux with latin-1 locale. Recently it was replaced by a
> Kubuntu distribution with utf-8 locale.

Fairly common situation.

> Over the years we have accumulated a large number of latin-1 files
> that were created and edited by people who are no longer in the group
> and who used whichever editors they liked. Some files may contain as
> part of their text content information about the coding system:
> "\usepackage[latin1]{inputenc}" in a LaTeX file,
> "<?xml version='1.0' encoding='iso-8859-1'?>" in an XML file,
> "<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1'>"
> in an HTML file. Probably there are similar examples for other formats.

Those xml/latex statement should be understood by Emacs as coding
cookies, so the files that contain those statements should be handled
properly with Emacs-23.2.

> Depending on the format the files may also contain some form of
> include mechanism that refers to a different file whose text
> content contains such coding information.

Yes, this is a more problematic case, because fundamentally there is
a coding-cookie, but Emacs doesn't know it because it's in another file.

> I don't know how frequent our situation is, but I guess that
> it is not uncommon in university environments in countries
> whose language needed one of the ISO-latin extensions of ASCII.

That was helpful, thank you.  I think you're right that we should at
least do a y-or-n-p prompt when changing the buffer-file-coding-system,
unless the change is to a "superset coding system" (like from us-ascii
to latin-1).

Can you try the patch below to see if it gives you the behavior you want?


        Stefan


=== modified file 'lisp/international/mule-cmds.el'
--- lisp/international/mule-cmds.el	2009-10-24 18:33:25 +0000
+++ lisp/international/mule-cmds.el	2009-10-30 15:01:02 +0000
@@ -979,6 +979,17 @@
 	(if safe
 	    (setq coding-system (car safe))))
 
+      (unless (or (local-variable-p 'buffer-file-coding-system)
+                  (eq coding-system buffer-file-coding-system)
+                  ;; We'd rather only bother the user if the coding-system
+                  ;; change would cause the file's content to change, so we'd
+                  ;; want to check whether the new coding-system is a superset
+                  ;; of the previous one.
+                  (memq buffer-file-coding-system '(nil undecided us-ascii))
+                  (y-or-n-p (format "Change encoding from %s to %s? "
+                                    buffer-file-coding-system coding-system)))
+        (setq coding-system nil))
+
       ;; If all the defaults failed, ask a user.
       (when (not coding-system)
 	(setq coding-system (select-safe-coding-system-interactively
@@ -1024,6 +1035,7 @@
 %s specified by file contents.  Really save (else edit coding cookies \
 and try again)? " coding-system auto-cs))
 	      (error "Save aborted"))))
+
       (when (and tick (/= tick (buffer-chars-modified-tick)))
 	(error "Cancelled because the buffer was modified"))
       coding-system)))




This bug report was last modified 5 years and 183 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.