unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: eisinger@informatik.uni-muenchen.de
Cc: 4816@emacsbugs.donarmstrong.com
Subject: bug#4816: change of coding system without inquiry
Date: Fri, 30 Oct 2009 11:02:49 -0400	[thread overview]
Message-ID: <jwvr5sl9c7g.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <4AEAE7F8.6010609@informatik.uni-muenchen.de> (Norbert Eisinger's message of "Fri, 30 Oct 2009 14:19:52 +0100")

> 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)))






  reply	other threads:[~2009-10-30 15:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27 23:03 bug#4816: change of coding system without inquiry Norbert Eisinger
2009-10-30  0:57 ` Stefan Monnier
2009-10-30 13:19   ` Norbert Eisinger
2009-10-30 15:02     ` Stefan Monnier [this message]
2009-10-30 15:47       ` Eli Zaretskii
2009-10-31 16:32       ` Norbert Eisinger
2009-11-01 18:33       ` Eli Zaretskii
2009-11-02  7:05         ` Stefan Monnier
2019-06-27 17:49       ` Lars Ingebrigtsen
2019-06-27 18:41         ` Eli Zaretskii
2019-11-23 12:55           ` Lars Ingebrigtsen
2016-02-28  6:37 ` Lars Ingebrigtsen
2016-02-28 15:46   ` Eli Zaretskii
2016-02-29  2:35     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvr5sl9c7g.fsf-monnier+emacsbugreports@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=4816@emacsbugs.donarmstrong.com \
    --cc=eisinger@informatik.uni-muenchen.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).