I just verified by cherrypicking your latest master checkin onto
7.8.05, and verified it working.
Hideki Saito
Google+: http://goo.gl/dVU2q
Facebook: http://goo.gl/RV5C8 http://goo.gl/FDeAw
On Sun, Mar 18, 2012 at 12:01 PM, David Maus wrote:
> At Sat, 3 Mar 2012 23:29:43 -0800,
> Hideki Saito
At Sat, 3 Mar 2012 23:29:43 -0800,
Hideki Saito wrote:
>
> [1 ]
> The attached is alternative of the patch using utf-8 encoding.
Thanks for the translation. I made the modification but we need to use
numeric character entities[1] to avoid rendering problems when
non-UTF8 documents are exported to
I was looking at those. Those seems to be table for replacement table
for special characters and symbols.
Are you suggesting placing those characters in this and reference from
main code? (that will be 8 characters which will not have any Latin1
and ASCII representations...)
Hideki Saito
On Sun
Hideki Saito writes:
> If UTF-8 strings are acceptable in org-mode source tree, I guess doing
> it so will make it most compatible.
M-x find-library RET org-entities RET
C-s lambda
will land you in a structure that has utf-8 strings.
--
Dear Saito-san,
Thanks for making an alternative patch.
I'll follow up why I cannot apply the original patch.
Best regards,
Takaaki Ishikawa
On 2012/03/04, at 16:29, Hideki Saito wrote:
> The attached is alternative of the patch using utf-8 encoding.
>
> Hideki Saito
>
>
>
> On Sat, Mar 3,
The attached is alternative of the patch using utf-8 encoding.
Hideki Saito
On Sat, Mar 3, 2012 at 10:26 PM, Hideki Saito wrote:
> Hello Ishikiawa-san
> It is OSX at work, and it's still on Snow Leopard -- I haven't updated
> the console version of it, so I will have to check to see which
> v
Hello Ishikiawa-san
It is OSX at work, and it's still on Snow Leopard -- I haven't updated
the console version of it, so I will have to check to see which
version was it. It is now sound like to me that the way I've done on
the patch is platform dependent at best -- which is strange as this
notatio
Dear Saito-san,
Thank you for comment.
You mean OSX+emacs23 users cannot compile using the patch, right?
(Or something wrong with me...)
And I can compile it in SuSE Linux :-)
Best regards,
Takaaki Ishikawa
On 2012/03/04, at 14:37, Hideki Saito wrote:
> Ishikawa-san,
> I've had that problem whe
Ishikawa-san,
I've had that problem when I tried to do "make' on Mac OS X, which I
realized it was compiling in obsolete version of emacs. (like emacs
22) I believe it was happening when (require 'org-exp.el)
In fact, I did see this would work if UTF-8ed in your example even in
the above environme
Dear Saito-san,
I've tried to compile your patch with the latest org-mode.
I got an error message:
Error: Invalid character: 33879, #o102127, #x8457
I can apply the following line directly under UTF-8 env.:
("ja" "著者" "日付" "目次" "脚注")
Emacs 23.4 (nextstep)
Org-version 7.8.03
Could you g
I think Gmail did bad to the patch snippet. Obviously, I haven't done
much of patch contributions :-)
I've attached one, or you can refer to:
https://gist.github.com/1964802
Thank you.
Hideki Saito
On Fri, Mar 2, 2012 at 5:55 PM, Hideki Saito wrote:
> diff --git a/lisp/org-exp.el b/lisp/org-
Hello,
I would like to submit a patch adding Japanese text string for export.
The following adds Japanese strings for "Author" "Date" "Table of
Contents" and "Footnotes"
Thank you.
Hideki Saito
diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 174619a..43c54b5 100644
--- a/lisp/org-exp.el
+
12 matches
Mail list logo
