From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: [Bug] Export Coding System
Date: Fri, 22 Feb 2013 23:09:02 +0100 [thread overview]
Message-ID: <874nh4j91d.fsf@gmail.com> (raw)
In-Reply-To: <87ehg8nika.fsf@Rainer.invalid> (Achim Gratz's message of "Fri, 22 Feb 2013 22:29:41 +0100")
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Achim Gratz <Stromeko@nexgo.de> writes:
> Nicolas Goaziou writes:
>>> Depends on what language environment is set to, but with the default setting of
>>> my Emacs (German) it becomes iso-latin-1, independently of what the coding
>>> system in the original Org buffer was.
>>
>> In this case, it should be `utf-8', shouldn't it?
>
> I want it to be utf-8, but it isn't. The course of events is apparently
> that when a new buffer gets created it will have the default coding
> system. You are then apparently asking that buffer for the coding
> system (always the default) and set inputenc accordingly, but should
> have asked the parent Org buffer. Or so I think, a few details are
> probably still wrong.
>
>>> I think that the export buffer coding system should be explicitly set (via
>>> buffer-file-coding-system, which is automatically buffer-local) to copy the
>>> coding of the parent buffer (or the coding specified via export options if
>>> anything like that exists) so that the default choice of the language
>>> environment doesn't kick in.
>>
>> Still trying to understand: is the coding system wrong when you export
>> to a file, to a (temporary) buffer, or both?
>
> Both.
>
>> Note that `org-export-to-file' use `coding-system-for-write', which
>> overrides `buffer-file-coding-system'. So this variable is probably
>> irrelevant here.
>
> No it is not irrelevant, it simply gets set too late in the game: it
> asks for the new coding system when it is time to save the buffer, while
> the content of the buffer has been cobbled together while assuming a
> different coding system. The only way I know (from browsing the
> documentation) to override the coding system for a buffer that does not
> yet have a file association is to set that variable directly,
> preferrably directly after the buffer is created.
Does the following patch fix the problem?
Regards,
--
Nicolas Goaziou
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Fix encoding problem --]
[-- Type: text/x-patch, Size: 1237 bytes --]
From ed16f38854c197e8b31607bd32622d00e47fe10c Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Fri, 22 Feb 2013 23:07:04 +0100
Subject: [PATCH] ox: Fix coding system error
* lisp/ox.el (org-export--generate-copy-script): Clone
`buffer-file-coding-system' when creating a buffer copy.
This patches makes sure the output will share the same encoding as the
original buffer.
---
lisp/ox.el | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index efce29d..65e5acd 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2729,10 +2729,13 @@ another buffer, effectively cloning the original buffer there."
(val (cdr entry)))
(and (not (eq var 'org-font-lock-keywords))
(or (memq var
- '(major-mode default-directory
- buffer-file-name outline-level
- outline-regexp
- buffer-invisibility-spec))
+ '(major-mode
+ default-directory
+ buffer-file-name
+ buffer-file-coding-system
+ outline-level
+ outline-regexp
+ buffer-invisibility-spec))
(string-match "^\\(org-\\|orgtbl-\\)"
(symbol-name var)))
;; Skip unreadable values, as they cannot be
--
1.8.1.4
next prev parent reply other threads:[~2013-02-22 22:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 10:28 [Bug] Export Coding System Achim Gratz
2013-02-22 13:19 ` Nicolas Goaziou
2013-02-22 15:06 ` Achim Gratz
2013-02-22 16:23 ` Nicolas Goaziou
2013-02-22 21:29 ` Achim Gratz
2013-02-22 22:09 ` Nicolas Goaziou [this message]
2013-02-23 9:29 ` Achim Gratz
2013-02-23 10:31 ` Nicolas Goaziou
2013-02-23 11:35 ` Achim Gratz
2013-02-23 13:00 ` Nicolas Goaziou
2013-02-23 13:31 ` Achim Gratz
2013-02-23 13:58 ` Nicolas Goaziou
2013-02-23 15:35 ` Achim Gratz
2013-02-26 12:50 ` Achim Gratz
2013-02-26 17:51 ` Achim Gratz
2013-02-27 13:40 ` Nicolas Goaziou
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.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874nh4j91d.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=Stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/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/org-mode.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).