Support Freemind/Freeplane export

Support Freemind/Freeplane export

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]


I have added support for Freemind/Freeplane Mindmap export.  I am
attaching sample files produced with the new exporter.

You are welcome to merge the changes to Org repo.

,---- http://repo.or.cz/w/org-mode/org-kjn.git
| URL	git://repo.or.cz/org-mode/org-kjn.git
| 	http://repo.or.cz/r/org-mode/org-kjn.git
`----

,----
| kjambunathan@debian-6:~/src/org-mode$ git log upstream/master..
| commit 0d49f12f61cf6799f22f1fc4d8cbbef78a67a315
| Author: Jambunathan K <kjambunathan@gmail.com>
| Date:   Sat Mar 2 11:00:46 2013 +0530
| 
|     lisp/ox-freemind.el: Freemind Mindmap Back-End for Org Export Engine
|     
|     * lisp/ox-freemind.el: New file.  Freemind Mindmap Back-End
|     for Org Export Engine.
|     
|     * lisp/ox-html.el (org-html--tags, org-html-format-headline)
|     (org-html--format-toc-headline, org-html-checkbox)
|     (org-html-table-cell, org-html-timestamp)
|     (org-html-verse-block, org-html-special-string-regexps):
|     Replace named HTML entities with their numeric counterparts.
|     This keeps Freemind backend happy.
`----




-- 

[-- Attachment #2: emacs-24.4-news.jpg --]
[-- Type: image/jpeg, Size: 327867 bytes --]

[-- Attachment #3: emacs-24.4-news.mm --]
[-- Type: application/x-freemind, Size: 40730 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: emacs-24.4-news.org --]
[-- Type: text/x-org, Size: 12245 bytes --]

#+TITLE: Emacs 24.4 News
#+OPTIONS: H:2 

\f
* Installation Changes in Emacs 24.4

** Emacs can be compiled with POSIX ACL support.
This happens by default if a suitable support library is found at
build time, like libacl on GNU/Linux.  To prevent this, use the
configure option `--without-acl'.

** The configure option --with-crt-dir has been removed.
It is no longer needed, as the crt*.o files are no longer linked specially.

\f
* Startup Changes in Emacs 24.4

\f
* Changes in Emacs 24.4

+++
** `apropos-variable' is now `apropos-user-option'
`apropos-user-option' shows all user options while `apropos-variable'
shows all variables.  When called with a universal prefix argument,
the two commands swap their behaviors.  When `apropos-do-all' is
non-nil, they output the same results.

+++
** `eval-defun' on an already defined defcustom calls the :set function,
if there is one.

** If the new variable `enable-dir-local-variables' is nil,
directory local variables are ignored.  May be useful for some modes
that want to ignore directory-locals while still respecting file-locals.

** The option `set-mark-default-inactive' has been deleted.
This unfinished feature was introduced by accident in Emacs 23.1;
simply disabling Transient Mark mode does the same thing.

** `initial-buffer-choice' can now specify a function to set up the
initial buffer.

** ACL support has been added.
+++
*** Emacs preserves the ACL entries of files when backing up.
+++
*** New functions `file-acl' and `set-file-acl' get and set the ACL
entries of a file.  On GNU/Linux, the POSIX ACL interface is used via
libacl.  On MS-Windows, the NT Security APIs are used to emulate the
POSIX ACL interfaces.

** New option `scroll-bar-adjust-thumb-portion'.
Available only on X, this option allows to control over-scrolling
using the scroll bar (i.e. dragging the thumb down even when the end
of the buffer is visible).

\f
* Editing Changes in Emacs 24.4

** New commands `toggle-frame-fullscreen' and `toggle-frame-maximized',
bound to <f11> and M-<f10>, respectively.

** In keymaps where SPC scrolls, S-SPC now scrolls in the reverse direction.
Eg View mode, etc.

\f
* Changes in Specialized Modes and Packages in Emacs 24.4

** Delphi mode is now called OPascal mode.
*** All delphi-* variables and functions have been renamed to opascal-*.
*** `delphi-newline-always-indents' is not supported any more
use `electric-indent-mode' instead.
*** `delphi-tab' is gone, replaced by `indent-for-tab-command'.

** jit-lock-debug-mode lets you use the debuggers on code run via jit-lock.

** completing-read-multiple's separator can now be a regexp.
The default separator is changed to allow surrounding spaces around the comma.

** Battery

*** Battery information via the BSD `apm' utility is now supported.

** cl-lib

*** New macro cl-tagbody.

+++
*** letf is now just an alias for cl-letf.

** Calc

*** Calc by default now uses the Gregorian calendar for all dates, and
uses January 1, 1 AD as its day number 1.  Previously Calc used the
Julian calendar for dates before September 14, 1752, and it used
December 31, 1 BC as its day number 1; the new scheme is more
consistent with Calendar's calendrical system and day numbering.

*** The new variable `calc-gregorian-switch' lets you configure the
date when Calc switches from the Julian to the Gregorian calendar.
Nil, the default value, means to always use the Gregorian calendar.
The value (YEAR MONTH DAY) means to start using the Gregorian calendar
on the given date.

*** Support for ISO 8601 dates.

** Dired

*** New minor mode `dired-hide-details-mode' hides details.

** ERC

*** New option `erc-accidental-paste-threshold-seconds'.
If set to a number, this can be used to avoid accidentally paste large
amounts of data into the ERC input.

** Icomplete is a bit more like IDO.
*** key bindings to navigate through and select the completions.
*** The icomplete-separator is customizable, and its default has changed.
*** Removed icomplete-show-key-bindings.

** Image mode

*** New commands `n' (`image-next-file') and `p' (`image-previous-file')
visit the next image file and the previous image file in the same
directory, respectively.

*** New commands to show specific frames of multi-frame images.
`f' (`image-next-frame') and `b' (`image-previous-frame') visit the
next or previous frame.  `F' (`image-goto-frame') shows a specific frame.

---
*** The command `image-mode-fit-frame' deletes other windows.
When toggling, it restores the frame's previous window configuration.
It also has an optional frame argument, which can be used by Lisp
callers to fit the image to a frame other than the selected frame.

** Isearch

*** `C-x 8 RET' in Isearch mode reads a character by its Unicode name
and adds it to the search string.

** MH-E has been updated to MH-E version 8.4.
See MH-E-NEWS for details.

---
** The unrmail command converts from BABYL to mboxrd rather than mboxo.
Customize `unrmail-mbox-format' to change this.

---
** Similarly, customize `rmail-mbox-format' to influence some minor aspects
of how Rmail displays non-MIME messages.

+++
** New function `ses-rename-cell' to give SES cells arbitrary names.

** trace-function was largely rewritten.
New features include:
- no prompting for the destination buffer, unless a prefix-arg was used.
- additionally to prompting for a destination buffer, when a prefix-arg is
  used, the user can enter a "context", i.e. Lisp expression whose value at the
  time the function is entered/exited will be printed along with the function
  name and arguments.  Useful to trace the value of (current-buffer) or
  (point) when the function is invoked.

** New command `delete-duplicate-lines' has two types of operation:
when its arg ADJACENT is non-nil (when called interactively with C-u C-u)
it works like the utility `uniq'.  Otherwise by default it deletes
duplicate lines everywhere in the region without regard to adjacency.

** New `cycle-spacing' command allows cycling between having just one
space, no spaces, or reverting to the original spacing.  Like
`just-one-space' command it can handle or ignore newlines and
leave different number of spaces.

** Tramp

+++
*** New connection method "adb", which allows to access Android
devices by the Android Debug Bridge.  The variable `tramp-adb-program'
can be used to adapt the path of the "adb" program, if needed.

*** The connection methods "plink1", "ssh1", "ssh2", "scp1", "scp2",
"scpc" and "rsyncc" are discontinued.  The ssh option
"ControlMaster=auto" is set automatically in all ssh-based methods,
when possible.

+++
*** Handlers for `file-acl' and `set-file-acl' for remote machines
which support POSIX ACLs.

** Woman

*** The commands `woman-default-faces' and `woman-monochrome-faces'
are obsolete.  Customize the `woman-* faces instead.

** Obsolete packages:

*** longlines.el is obsolete; use visual-line-mode instead.

*** terminal.el is obsolete; use term.el instead.

+++
*** yow.el is obsolete; use fortune.el or cookie1.el instead.

---
*** The Info-edit command is obsolete.  Editing Info nodes by hand
has not been relevant for some time.

\f
* New Modes and Packages in Emacs 24.4
** New nadvice.el package offering lighter-weight advice facilities.
It is layered as:
- add-function/remove-function which can be used to add/remove code on any
  function-carrying place, such as process-filters or `<foo>-function' hooks.
- advice-add/advice-remove to add/remove a piece of advice on a named function,
  much like `defadvice' does.

\f
* Incompatible Lisp Changes in Emacs 24.4

** Removed inhibit-local-menu-bar-menus.

** frame-local variables that affect redisplay do not work any more.
More specifically, the redisplay does not bother to check for a frame-local
value when looking up variables.

** nil and "unbound" are indistinguishable in symbol-function.
`symbol-function' never signals `void-function' any more.
`fboundp' returns non-nil if the symbol was `fset' to nil.

** `defadvice' does not honor the `freeze' flag and cannot advise
special-forms any more.

** `dolist' in lexical-binding mode does not bind VAR in RESULT any more.
VAR was bound to nil which was not tremendously useful and just lead to
spurious warnings about an unused var.

** The return value of `backup-buffer' has changed.
The second argument is no longer an SELinux context, instead it is an
alist of extended attributes as returned by the new function
`file-extended-attributes'.  The attributes can be applied to another
file using `set-file-extended-attributes'.

\f
* Lisp Changes in Emacs 24.4

** Support for filesystem notifications.
Emacs now supports notifications of filesystem changes, such as
creation, modification, and deletion of files.  This requires the
'inotify' API on GNU/Linux systems.  On MS-Windows systems, this is
supported for Windows XP and newer versions.

** Changes in autorevert.el

---
*** If Emacs is compiled with file notification support, notifications
are used instead of checking the time stamp of the files.  You can
disable this by setting the user option `auto-revert-use-notify' to
nil.  Alternatively, a regular expression of directories to be
excluded from file notifications can be specified by
`auto-revert-notify-exclude-dir-regexp'.

---
*** The new user option `auto-revert-remote-files' enables reversion
of remote files when set to non-nil.

** Face changes

*** The `face-spec-set' is now analogous to `setq' for face specs.
Its third arg now accepts values specifying exactly which face spec to
set (defface, custom, or user spec), and it directly sets the relevant
property using the supplied face spec.

*** Face specs set via Custom themes now replace the `defface' spec
rather than inheriting from it (as do face specs set via Customize).

*** New face characteristic (supports :underline (:style wave))
specifies whether or not the terminal can display a wavy line.

** Image API

+++
*** `image-animated-p' is now `image-multi-frame-p'.
It returns non-nil for any image that contains multiple frames,
whether or not it specifies a frame delay.

+++
*** When animating images that do not specify a frame delay,
Emacs uses `image-default-frame-delay'.

+++
*** New functions `image-current-frame' and `image-show-frame' for getting
and setting the current frame of a multi-frame image.

** time-to-seconds is not obsolete any more.
** New function special-form-p.
** Docstrings can be made dynamic by adding a `dynamic-docstring-function'
text-property on the first char.

** The `defalias-fset-function' property lets you catch calls to defalias
and redirect them to your own function instead of `fset'.

** The 9th element returned by `file-attributes' is now unspecified.
Formerly, it was t if the file's gid would change if file were deleted
and recreated.  This value has been inaccurate for years on many
platforms, and nobody seems to have noticed or cared.

** The function `file-ownership-preserved-p' now has an optional
argument GROUP which causes it check for file group too.  This can be
used in place of the 9th element of `file-attributes'.

** New functions `group-gid' and `group-real-gid'.

** The 6th argument to `copy-file' has been renamed to
`preserve-extended-attributes' as it now handles both SELinux context
and ACL entries.

\f
* Changes in Emacs 24.4 on Non-Free Operating Systems

+++
** The "generate a backtrace on fatal error" feature now works on MS Windows.
The backtrace is written to the 'emacs_backtrace.txt' file in the
directory where Emacs was running.

+++
** The variable `buffer-file-type' is no longer supported.
Setting it has no effect, and %t in the mode-line format is ignored.
Likewise, `file-name-buffer-file-type-alist' is now obsolete, and
modifying it has no effect.

---
** Lock files now work on MS-Windows.
This allows to avoid losing your edits if the same file is being
edited in another Emacs session or by another user.  See the node
"Interlocking" in the Emacs User Manual for the details.  To disable
file locking, customize `create-lockfiles' to nil.

** Improved fullscreen support on Mac OS X.
Both native (>= OSX 10.7) and "old style" fullscreen are supported.
Customize `ns-use-native-fullscreen' to change style.  For >= 10.7
native is the default.

\f

Re: Support Freemind/Freeplane export

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> I have added support for Freemind/Freeplane Mindmap export.  I am
> attaching sample files produced with the new exporter.
>
> You are welcome to merge the changes to Org repo.

Done. Thank you!


Regards,

-- 
Nicolas Goaziou

Re: Support Freemind/Freeplane export

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> I have added support for Freemind/Freeplane Mindmap export.  I am
>> attaching sample files produced with the new exporter.
>>
>> You are welcome to merge the changes to Org repo.
>
> Done. Thank you!

We encourage contributors without commit access to share patches on
the list so that everyone can review and test them.

Let's stick to this policy and avoid applying patches that have been
sent in private -- I always ask people who send me patches in private
to send them to the list.

Also, the change in ox-html.el is not good IMHO: it will populate
everyone's HTML code with unfamiliar strings (like "&#xa0;" instead
of "&nbsp;") just for the sake of keeping ox-freemind.el users happy.

Is there no other way to get the same result for the Freemind export?

Thanks,

-- 
 Bastien

Re: Support Freemind/Freeplane export

[Bastien]

Bastien <bzg@altern.org> writes:

> We encourage contributors without commit access to share patches on
> the list so that everyone can review and test them.

Ignore this, I just received Jambunathan contribution on the list.

Thanks for applying it, and thanks for the patch Jambunathan.

I'm still wondering if we can use &nbsp; instead of the numeric
representation.  Jambunathan, do you have any idea?

-- 
 Bastien

Re: Support Freemind/Freeplane export

[Achim Gratz]

Bastien writes:
> Also, the change in ox-html.el is not good IMHO: it will populate
> everyone's HTML code with unfamiliar strings (like " " instead
> of " ") just for the sake of keeping ox-freemind.el users happy.

It also requires that the HTML is output in UTF-8.  I would
(reluctantly, I don't really know much about how this would work)
suggest that the export should always be done with symbolic entities and
a post-export filter should then replace them with whatever the
particular backend prefers.  Does that work?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Support Freemind/Freeplane export

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> It also requires that the HTML is output in UTF-8.  I would
> (reluctantly, I don't really know much about how this would work)
> suggest that the export should always be done with symbolic entities and
> a post-export filter should then replace them with whatever the
> particular backend prefers.  Does that work?

This seems a good idea to me.  Nicolas, do you think so?

-- 
 Bastien

Re: Support Freemind/Freeplane export

[Nicolas Goaziou]

Bastien <bzg@altern.org> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> It also requires that the HTML is output in UTF-8.  I would
>> (reluctantly, I don't really know much about how this would work)
>> suggest that the export should always be done with symbolic entities and
>> a post-export filter should then replace them with whatever the
>> particular backend prefers.  Does that work?
>
> This seems a good idea to me.  Nicolas, do you think so?

Yes. We can add a defconst associating each HTML entity to its utf-8
counterpart, and add a filter to :filter-final-output in freemind
back-end definition (not to `org-export-filter-final-output-functions',
which is user-oriented).

Any taker? Jambunathan?


Regards,

-- 
Nicolas Goaziou

Re: Support Freemind/Freeplane export

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>
>>> It also requires that the HTML is output in UTF-8.  I would
>>> (reluctantly, I don't really know much about how this would work)
>>> suggest that the export should always be done with symbolic entities and
>>> a post-export filter should then replace them with whatever the
>>> particular backend prefers.  Does that work?
>>
>> This seems a good idea to me.  Nicolas, do you think so?
>
> Yes. We can add a defconst associating each HTML entity to its utf-8
> counterpart, and add a filter to :filter-final-output in freemind
> back-end definition (not to `org-export-filter-final-output-functions',
> which is user-oriented).
>
> Any taker? Jambunathan?

Please merge 

,---- http://repo.or.cz/w/org-mode/org-kjn.git
|
| URL	git://repo.or.cz/org-mode/org-kjn.git
| 	http://repo.or.cz/r/org-mode/org-kjn.git
|
`----

I will submit more changes to ox-html.el and ox-odt.el.  It's going to
some time though.

ps: I have a feeling that `org-html-display-buffer-mode' is superfluous.
A simple `set-auto-mode' will do the trick.

,----
| kjambunathan@debian-6:~/src/org-mode$ git log upstream/master..
| commit b8d0b1ae89bd769a898aba90f6c85c680963e0ed
| Author: Jambunathan K <kjambunathan@gmail.com>
| Date:   Sun Mar 3 20:21:07 2013 +0530
| 
|     doc/org.texi: Replace org-export-odt with org-odt
| 
| commit c5d46d21b5a3f902cfd7b9d709660b493f67bd94
| Author: Jambunathan K <kjambunathan@gmail.com>
| Date:   Sun Mar 3 20:15:10 2013 +0530
| 
|     Always use utf-8 encoding for HTML export
|     
|     * ox-html.el (org-html-coding-system): Removed.  Always use
|     utf-8 for HTML export.
|     (org-html--build-meta-info, org-html-template)
|     (org-html-entity, org-html-export-to-html): Propagate above
|     change.
|     (org-html-table--table.el-table): Replace &nbsp; with it's
|     utf-8 equivalent.
|     (org-html-special-string-regexps, org-html--tags)
|     (org-html-format-headline, org-html--format-toc-headline)
|     (org-html-checkbox, org-html-table-cell, org-html-timestamp)
|     (org-html-verse-block): Replace numeric entities with their
|     utf-8 equivalent.
|     
|     Mark ox-html.el as utf-8 encoded.
| 
| commit 75708cf644944d301e57bc343db8749b8fa3c242
| Author: Jambunathan K <kjambunathan@gmail.com>
| Date:   Sun Mar 3 13:51:32 2013 +0530
| 
|     ox-html.el (org-html-code, org-html-verbatim): Transcode value
|     
|     * lisp/ox-html.el (org-html-code, org-html-verbatim):
|     Transcode value.
`----



>
>
> Regards,

-- 

Re: Support Freemind/Freeplane export

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Bastien <bzg@altern.org> writes:
>>
>>> Achim Gratz <Stromeko@nexgo.de> writes:
>>>
>>>> It also requires that the HTML is output in UTF-8.  I would
>>>> (reluctantly, I don't really know much about how this would work)
>>>> suggest that the export should always be done with symbolic entities and
>>>> a post-export filter should then replace them with whatever the
>>>> particular backend prefers.  Does that work?
>>>
>>> This seems a good idea to me.  Nicolas, do you think so?
>>
>> Yes. We can add a defconst associating each HTML entity to its utf-8
>> counterpart, and add a filter to :filter-final-output in freemind
>> back-end definition (not to `org-export-filter-final-output-functions',
>> which is user-oriented).
>>
>> Any taker? Jambunathan?

>
> Please merge 
>
> ,---- http://repo.or.cz/w/org-mode/org-kjn.git
> |
> | URL	git://repo.or.cz/org-mode/org-kjn.git
> | 	http://repo.or.cz/r/org-mode/org-kjn.git
> |
> `----

Sorry for the double post.  Here comes the patch file(s).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-html.el-org-html-code-org-html-verbatim-Transcode.patch --]
[-- Type: text/x-diff, Size: 1155 bytes --]

From 75708cf644944d301e57bc343db8749b8fa3c242 Mon Sep 17 00:00:00 2001
From: Jambunathan K <kjambunathan@gmail.com>
Date: Sun, 3 Mar 2013 13:51:32 +0530
Subject: [PATCH 1/3] ox-html.el (org-html-code, org-html-verbatim): Transcode value

* lisp/ox-html.el (org-html-code, org-html-verbatim):
Transcode value.
---
 lisp/ox-html.el |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index a0f3f4f..3a4c0e7 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1899,7 +1899,7 @@ channel."
 CONTENTS is nil.  INFO is a plist holding contextual
 information."
   (format (or (cdr (assq 'code org-html-text-markup-alist)) "%s")
-	  (org-element-property :value code)))
+	  (org-html-plain-text (org-element-property :value code) info)))
 
 
 ;;;; Drawer
@@ -3029,7 +3029,7 @@ holding contextual information."
 CONTENTS is nil.  INFO is a plist holding contextual
 information."
   (format (or (cdr (assq 'verbatim org-html-text-markup-alist)) "%s")
-	  (org-element-property :value verbatim)))
+	  (org-html-plain-text (org-element-property :value verbatim) info)))
 
 
 ;;;; Verse Block
-- 
1.7.2.5


[-- Attachment #3: 0002-Always-use-utf-8-encoding-for-HTML-export.patch --]
[-- Type: text/x-diff, Size: 7349 bytes --]

From c5d46d21b5a3f902cfd7b9d709660b493f67bd94 Mon Sep 17 00:00:00 2001
From: Jambunathan K <kjambunathan@gmail.com>
Date: Sun, 3 Mar 2013 20:15:10 +0530
Subject: [PATCH 2/3] Always use utf-8 encoding for HTML export

* ox-html.el (org-html-coding-system): Removed.  Always use
utf-8 for HTML export.
(org-html--build-meta-info, org-html-template)
(org-html-entity, org-html-export-to-html): Propagate above
change.
(org-html-table--table.el-table): Replace &nbsp; with it's
utf-8 equivalent.
(org-html-special-string-regexps, org-html--tags)
(org-html-format-headline, org-html--format-toc-headline)
(org-html-checkbox, org-html-table-cell, org-html-timestamp)
(org-html-verse-block): Replace numeric entities with their
utf-8 equivalent.

Mark ox-html.el as utf-8 encoded.
---
 lisp/ox-html.el |   55 +++++++++++++++++++++----------------------------------
 1 files changed, 21 insertions(+), 34 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 3a4c0e7..efd9b2f 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -136,10 +136,10 @@
 (defvar htmlize-buffer-places)  ; from htmlize.el
 
 (defconst org-html-special-string-regexps
-  '(("\\\\-" . "&#x00ad;")		; shy
-    ("---\\([^-]\\)" . "&#x2014;\\1")	; mdash
-    ("--\\([^-]\\)" . "&#x2013;\\1")	; ndash
-    ("\\.\\.\\." . "&#x2026;"))		; hellip
+  '(("\\\\-" . "­")		; shy
+    ("---\\([^-]\\)" . "—\\1")	; mdash
+    ("--\\([^-]\\)" . "–\\1")	; ndash
+    ("\\.\\.\\." . "…"))	; hellip
   "Regular expressions for special string conversion.")
 
 (defconst org-html-scripts
@@ -821,12 +821,6 @@ and corresponding declarations."
 		  (cons (string :tag "Extension")
 			(string :tag "Declaration")))))
 
-(defcustom org-html-coding-system 'utf-8
-  "Coding system for HTML export.
-Use utf-8 as the default value."
-  :group 'org-export-html
-  :type 'coding-system)
-
 (defcustom org-html-divs '("preamble" "content" "postamble")
   "The name of the main divs for HTML export.
 This is a list of three strings, the first one for the preamble
@@ -1337,12 +1331,7 @@ INFO is a plist used as a communication channel."
 	 (keywords (plist-get info :keywords)))
     (concat
      (format "<title>%s</title>\n" title)
-     (format
-      "<meta http-equiv=\"Content-Type\" content=\"text/html;charset=%s\"/>\n"
-      (or (and org-html-coding-system
-	       (fboundp 'coding-system-get)
-	       (coding-system-get org-html-coding-system 'mime-charset))
-	  "iso-8859-1"))
+     "<meta http-equiv=\"Content-Type\" content=\"text/html;charset=utf-8\"/>\n"
      (format "<meta name=\"title\" content=\"%s\"/>\n" title)
      (format "<meta name=\"generator\" content=\"Org-mode\"/>\n")
      (and date (format "<meta name=\"generated\" content=\"%s\"/>\n" date))
@@ -1515,10 +1504,7 @@ holding export options."
 	(cdr (assoc "html" org-html-xml-declaration))
 
 	"")
-    (or (and org-html-coding-system
-	     (fboundp 'coding-system-get)
-	     (coding-system-get org-html-coding-system 'mime-charset))
-	"iso-8859-1"))
+    "utf-8")
    "\n"
    "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\"
 	       \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n"
@@ -1579,7 +1565,7 @@ INFO is a plist used as a communication channel."
 		       (concat org-html-tag-class-prefix
 			       (org-html-fix-class-name tag))
 		       tag))
-	     tags "&#xa0;"))))
+	     tags " "))))
 
 ;;;; Headline
 
@@ -1593,7 +1579,7 @@ INFO is a plist used as a communication channel."
 	(todo (org-html--todo todo))
 	(tags (org-html--tags tags)))
     (concat section-number todo (and todo " ") text
-	    (and tags "&#xa0;&#xa0;&#xa0;") tags)))
+	    (and tags "   ") tags)))
 
 ;;;; Src Code
 
@@ -1780,7 +1766,7 @@ INFO is a plist used as a communication channel."
 			(target . ignore))
 		      (org-export-backend-translate-table 'html))
 		     info)
-		    (and tags "&#xa0;&#xa0;&#xa0;") (org-html--tags tags)))))
+		    (and tags "   ") (org-html--tags tags)))))
 
 (defun org-html-list-of-listings (info)
   "Build a list of listings.
@@ -1932,7 +1918,7 @@ holding contextual information.  See `org-export-data'."
   "Transcode an ENTITY object from Org to HTML.
 CONTENTS are the definition itself.  INFO is a plist holding
 contextual information."
-  (org-element-property :html entity))
+  (org-element-property :utf-8 entity))
 
 
 ;;;; Example Block
@@ -2184,7 +2170,7 @@ contextual information."
 
 (defun org-html-checkbox (checkbox)
   (case checkbox (on "<code>[X]</code>")
-	(off "<code>[&#xa0;]</code>")
+	(off "<code>[ ]</code>")
 	(trans "<code>[-]</code>")
 	(t "")))
 
@@ -2856,7 +2842,7 @@ channel."
 			" align=\"%s\"" " class=\"%s\"")
 		    (org-export-table-cell-alignment table-cell info)))))
     (when (or (not contents) (string= "" (org-trim contents)))
-      (setq contents "&#xa0;"))
+      (setq contents " "))
     (cond
      ((and (org-export-table-has-header-p table info)
 	   (= 1 (org-export-table-row-group table-row info)))
@@ -2929,8 +2915,9 @@ communication channel."
 	(re-search-forward "^[ \t]*|[^|]" nil t)
 	(table-generate-source 'html outbuf))
       (with-current-buffer outbuf
-	(prog1 (org-trim (buffer-string))
-	  (kill-buffer) )))))
+	(prog1 (org-trim (replace-regexp-in-string
+			  "&nbsp;" " " (buffer-string) nil t))
+	  (kill-buffer))))))
 
 (defun org-html-table (table contents info)
   "Transcode a TABLE element from Org to HTML.
@@ -3009,7 +2996,7 @@ information."
   (let ((value (org-html-plain-text
 		(org-timestamp-translate timestamp) info)))
     (format "<span class=\"timestamp-wrapper\"><span class=\"timestamp\">%s</span></span>"
-	    (replace-regexp-in-string "--" "&#x2013;" value))))
+	    (replace-regexp-in-string "--" "–" value))))
 
 
 ;;;; Underline
@@ -3049,7 +3036,7 @@ contextual information."
   (while (string-match "^[ \t]+" contents)
     (let* ((num-ws (length (match-string 0 contents)))
 	   (ws (let (out) (dotimes (i num-ws out)
-			    (setq out (concat out "&#xa0;"))))))
+			    (setq out (concat out " "))))))
       (setq contents (replace-match ws nil t contents))))
   (format "<p class=\"verse\">\n%s</p>" contents))
 
@@ -3150,16 +3137,15 @@ file-local settings.
 Return output file's name."
   (interactive)
   (let* ((extension (concat "." org-html-extension))
-	 (file (org-export-output-file-name extension subtreep))
-	 (org-export-coding-system org-html-coding-system))
+	 (file (org-export-output-file-name extension subtreep)))
     (if async
 	(org-export-async-start
 	    (lambda (f) (org-export-add-to-stack f 'html))
-	  (let ((org-export-coding-system org-html-coding-system))
+	  (let ((org-export-coding-system 'utf-8))
 	    `(expand-file-name
 	      (org-export-to-file
 	       'html ,file ,subtreep ,visible-only ,body-only ',ext-plist))))
-      (let ((org-export-coding-system org-html-coding-system))
+      (let ((org-export-coding-system 'utf-8))
 	(org-export-to-file
 	 'html file subtreep visible-only body-only ext-plist)))))
 
@@ -3199,6 +3185,7 @@ Return output file name."
 
 ;; Local variables:
 ;; generated-autoload-file: "org-loaddefs.el"
+;; coding: utf-8
 ;; End:
 
 ;;; ox-html.el ends here
-- 
1.7.2.5


[-- Attachment #4: Type: text/plain, Size: 6 bytes --]



-- 

Re: Support Freemind/Freeplane export

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> ps: I have a feeling that `org-html-display-buffer-mode' is superfluous.
> A simple `set-auto-mode' will do the trick.

Indeed, I applied a patch using `set-auto-mode'. 
Thanks for the suggestion!

-- 
 Bastien

Re: Support Freemind/Freeplane export

[Jambunathan K]

Bastien <bzg@altern.org> writes:

> Also, the change in ox-html.el is not good IMHO: it will populate
> everyone's HTML code with unfamiliar strings (like "&#xa0;" instead
> of "&nbsp;") just for the sake of keeping ox-freemind.el users happy.

How many people are going to read HTML code?  There is correctness and
there is readability.  Those who actually read HTML code better know
what they are looking at.  Remember the character in question are
occurring here and there and not everywhere.

Adding a filter function will only add a moving part.  It could be a
robust moving part, but it is a moving part nevertheless.

In short, the concern you have raised is more cosmetic than functional.

-- 

Always use utf-8 for HTML export (No support for other coding systems)

[Jambunathan K]

Always use utf-8 for HTML export (No support for other coding systems).

For or against.  Please register your views.
-- 

Re: Support Freemind/Freeplane export

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> In short, the concern you have raised is more cosmetic than
> functional.

I trust you.  The thing is, I have this small incertainty in my
mind on whether there is something functional involved here or not.

Also, IIUC the change is triggered only because ox-freemind.el needs
it, so the little incertainty + why it's needed makes me think twice.

Is it fine to assume that all users want utf8 for their HTML files?

If so, I'm fine with the patch.

I'm just asking confirmation from (other) HTML/coding system experts.
Achim, what do you think?

(The local variable "coding: utf-8" should be "coding: utf-8-emacs"
I think.)

-- 
 Bastien

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Achim Gratz]

Jambunathan K writes:
> Always use utf-8 for HTML export (No support for other coding systems).
>
> For or against.  Please register your views.

It is becoming more rare these days, but still possible that the
document encoding cannot be UTF-8 for whatever reason.  So if it's not
unduly complicating things, I'd suggest to avoid prescribing the UTF-8
encoding for any and all exports.

Character entities and character entity references are what
SGML/XML/HTML are using to get around that problem (the markup languages
are all defined as operating on UCS), however the set of entitiy
references defined by default is different, which makes the numeric
character entities the most portable (unfortunately they are less
readable).

Remark: IIUC, this is what derails the (HTML, but not XML) symbolic
entities in Freemind.  It might be possible to simply declare the DTD
defining these for XML in the freemind preamble.

http://www.w3.org/TR/xml-entity-names/

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Nagarjuna G]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On Sun, Mar 3, 2013 at 11:58 PM, Achim Gratz <Stromeko@nexgo.de> wrote:

> Jambunathan K writes:
> > Always use utf-8 for HTML export (No support for other coding systems).
> >
> > For or against.  Please register your views.
>
>
I am not sure if it effects our project.  We use org and Emacs for
post-processing  our wiki pages to produce html pages.  Currently we are
getting proper exports since we get the output in utf-8.  As far as I know,
using utf-8 will support other coding systems as well. Am I wrong?

-- 
GN

[-- Attachment #2: Type: text/html, Size: 843 bytes --]

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Achim Gratz]

Nagarjuna G writes:
> I am not sure if it effects our project. We use org and Emacs for
> post-processing our wiki pages to produce html pages. Currently we are
> getting proper exports since we get the output in utf-8. As far as I
> know, using utf-8 will support other coding systems as well. Am I
> wrong?

If you already use UTF-8 encoding for your HTML files, you can safely
ignore this discussion.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Support Freemind/Freeplane export

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>>> Bastien <bzg@altern.org> writes:
>>>
>>>> Achim Gratz <Stromeko@nexgo.de> writes:
>>>>
>>>>> It also requires that the HTML is output in UTF-8.  I would
>>>>> (reluctantly, I don't really know much about how this would work)
>>>>> suggest that the export should always be done with symbolic entities and
>>>>> a post-export filter should then replace them with whatever the
>>>>> particular backend prefers.  Does that work?
>>>>
>>>> This seems a good idea to me.  Nicolas, do you think so?
>>>
>>> Yes. We can add a defconst associating each HTML entity to its utf-8
>>> counterpart, and add a filter to :filter-final-output in freemind
>>> back-end definition (not to `org-export-filter-final-output-functions',
>>> which is user-oriented).
>>>
>>> Any taker? Jambunathan?
>
>>
>> Please merge 
>>
>> ,---- http://repo.or.cz/w/org-mode/org-kjn.git
>> |
>> | URL	git://repo.or.cz/org-mode/org-kjn.git
>> | 	http://repo.or.cz/r/org-mode/org-kjn.git
>> |
>> `----
>
> Sorry for the double post.  Here comes the patch file(s).

I have applied the first patch (about verbatim and code markup), the
other one still being debated.

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Robert Horn]

Achim Gratz writes:

> Jambunathan K writes:
>> Always use utf-8 for HTML export (No support for other coding systems).
>>
>> For or against.  Please register your views.
>
> It is becoming more rare these days, but still possible that the
> document encoding cannot be UTF-8 for whatever reason.  So if it's not
> unduly complicating things, I'd suggest to avoid prescribing the UTF-8
> encoding for any and all exports.
>

Chinese law mandates use of GB-18030, not UTF-8.  The two are losslessly
and unambiguously convertable, but their bit encodings are different.
They are accustomed to dealing with UTF-8 from other parts of the world,
but might prefer to generate local pages in compliance with the law.

R Horn
rjhorn@alum.mit.edu

Re: Support Freemind/Freeplane export

[François Pinard]

Jambunathan K <kjambunathan@gmail.com> writes:

> How many people are going to read HTML code?  [...]  In short, the
> concern you have raised is more cosmetic than functional.

Replying to the org-mode mailing list.  I did not closely followed the
discussion, so maybe I'm missing the point.

A lot of people are not going to read HTML, but it does not mean that
nobody does.  Many people still read HTML code, for a variety of
reasons.  I find HTML code should stay as legible as possible.

As long as legibility is at stake, character entities are a pain in the
neck (or anywhere else of your choice along the spine!).  So, if the
charset of the HTML can be ascertained, usually within the headers, the
remainder of the HTML file should take full advantage of it, and limit
character entities as much as possible.

Character set entities are meaningful when the HTML file does not
declare a charset.  They should be avoided otherwise, in my opinion.

François

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Jambunathan K]

Robert Horn <rjhorn@alum.mit.edu> writes:

> Achim Gratz writes:
>
>> Jambunathan K writes:
>>> Always use utf-8 for HTML export (No support for other coding systems).
>>>
>>> For or against.  Please register your views.
>>
>> It is becoming more rare these days, but still possible that the
>> document encoding cannot be UTF-8 for whatever reason.  So if it's not
>> unduly complicating things, I'd suggest to avoid prescribing the UTF-8
>> encoding for any and all exports.
>>
>
> Chinese law mandates use of GB-18030, not UTF-8.  The two are losslessly
> and unambiguously convertable, but their bit encodings are different.
> They are accustomed to dealing with UTF-8 from other parts of the world,
> but might prefer to generate local pages in compliance with the law.

My proposal and patch to always use utf-8 stands annulled then.

> R Horn
> rjhorn@alum.mit.edu
>
>

-- 

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> My proposal and patch to always use utf-8 stands annulled then.

Okay.  I guess we shall go with the workaround solution for
ox-freemind.el, then.  Can you provide a patch for this?

Thanks!

-- 
 Bastien

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Robert Klein]

On 03/03/2013 06:47 PM, Jambunathan K wrote:
> 
> Always use utf-8 for HTML export (No support for other coding systems).
> 
> For or against.  Please register your views.
> 

Against.

Character set of a web document is determined by the /outermost/
"entity".  The outermost entity available is the web server.  If a web
server says, "This document is in iso-8859-1"  (instead of "I don't
care, which is pretty much the norm, today) the document better *is* in
iso-8859-1, or all the beautiful utf-8 characters are looking like Æ-{r
 or so.

Personally I prefer to use utf-8, too.  However, I've had a number of
uncooperative web servers (and operators), where I had to deliver
documents in 8859-1.

Best regards
Robert

Re: Always use utf-8 for HTML export (No support for other coding systems)

[Bastien]

Robert Klein <kleinrob@mpip-mainz.mpg.de> writes:

> Personally I prefer to use utf-8, too.  However, I've had a number of
> uncooperative web servers (and operators), where I had to deliver
> documents in 8859-1.

Mhh... yes, that's exactly what happened to me on a server.

Thanks for confirming it was a really memory, not a dream of mine.

-- 
 Bastien

Re: Support Freemind/Freeplane export

[Scott Randby]

On 03/03/2013 08:33 PM, François Pinard wrote:
> Jambunathan K <kjambunathan@gmail.com> writes:
> 
>> How many people are going to read HTML code?  [...]  In short, the
>> concern you have raised is more cosmetic than functional.
> 
> Replying to the org-mode mailing list.  I did not closely followed the
> discussion, so maybe I'm missing the point.
> 
> A lot of people are not going to read HTML, but it does not mean that
> nobody does.  Many people still read HTML code, for a variety of
> reasons.  I find HTML code should stay as legible as possible.

I agree. I read the HTML code that org generates and there other are
people who read the same code and don't use org. Legibility of the code
generated by org is a necessity for me.

Scott Randby