Current Org-mode does not work with Emacs 27

[Yasushi SHOJI]

Hi all,

 It appears that Emacs 27 lacks the optional argument for
`get-buffer-create`, while `org-element-parse-secondary-string`
relies on it. This problem was introduced by the commit 37d6bde27fe2.

Additionally, `org-id-find-id-in-file` also uses `get-buffer-create`
with a second argument, but it checks the function and has a condition
to call it with or without the argument.

Given that `org-compat.el` already contains compatibility functions
for different Emacs versions, should we create one for
`get-buffer-create` to address this issue? Since `org-compat.el`
provides compatibility layers for Emacs 26.1 and later, it's
reasonable to assume that Org mode still supports Emacs 27?

Thanks,
-- 
   yashi

Re: exporter: How to get :file property on a src block in an exporter

[Yasushi SHOJI]

Hi,

On Thu, Dec 23, 2021 at 3:22 AM Berry, Charles  wrote:
> > On Dec 22, 2021, at 8:07 AM, Yasushi SHOJI  wrote:
> > On Thu, Dec 23, 2021 at 12:52 AM Yasushi SHOJI  
> > wrote:
> >> Then, why don't I have :file in the info?
> >
> > The :exports must be "file" to have the file name in the info.  I used
> > to have "code" because
> > I wanted to export code with the file name as an attribute.
>
> I don't see that here:
>
> #+begin_src emacs-lisp :exports code :file abc
>   (assq :file (caddr (org-babel-get-src-block-info 'light)))
> #+end_src
>
> #+RESULTS:
> : (:file . abc)

Indeed, this one works.  But I don't see :file, or the whole
:parameters in the info arg passed to my function.

> `org-export-as' runs `org-babel-exp-process-buffer' *before*  it parses the 
> buffer and the header args get stripped from the copy buffer at that time.

Would you mind telling me where the stripping part is in the code, and
the reason why it strips?

> So you need to find a way to get the :file header arg whilst babel runs and 
> hang onto it for later use.

I'm still learning but :parameters, which holds :file, are already
gone from the info arg when org-myexporter-src-block is called.

Thanks,
-- 
yashi

Re: exporter: How to get :file property on a src block in an exporter

[Yasushi SHOJI]

On Thu, Dec 23, 2021 at 12:52 AM Yasushi SHOJI  wrote:
> Then, why don't I have :file in the info?

The :exports must be "file" to have the file name in the info.  I used
to have "code" because
I wanted to export code with the file name as an attribute.

I think I can work on it.

Thanks Ihor for your hint!

Best regards,
-- 
 yashi

Re: exporter: How to get :file property on a src block in an exporter

[Yasushi SHOJI]

Hi Ihor,

On Wed, Dec 22, 2021 at 11:32 PM Ihor Radchenko  wrote:
> Yasushi SHOJI  writes:
> > I'm writing an exporter and I'd like to get :file property on a src block.
> > Let's say I have the following src block in an org file.
> > ...
> > How can I get "images/hello-world.png" in org-myexporter-src-block?
>
> See org-babel-get-src-block-info. It can accept the parsed src-block element.

This is what I got from (org-bable-get-src-block-info nil src-block)

("ditaa" "+--+\n| Hello World! |\n+--+"
 ((:colname-names)
  (:rowname-names)
  (:result-params "replace")
  (:result-type . value)
  (:results . "replace")
  (:exports . "code")
  (:tangle . "no")
  (:hlines . "no")
  (:noweb . "no")
  (:cache . "no")
  (:session . "none"))
 "" nil 41 "(ref:%s)")

I don't see :file in it.  What am I missing?

I've been reading org-element-src-block-parser, but I'm not sure it's
parsing `:file` as ob does.
How does org-bable-execute:ditaa gets params, which I can get :file from?
I seems to me org-babel-exp-src-block -> org-babel-get-src-block-info ->
org-bable-exp-do-export -> 
Then, why don't I have :file in the info?

Thank you for your time.
-- 
 yashi

exporter: How to get :file property on a src block in an exporter

[Yasushi SHOJI]

Hi,

I'm writing an exporter and I'd like to get :file property on a src block.
Let's say I have the following src block in an org file.

#+BEGIN_SRC ditaa :file images/hello-world.png :exports code
+--+
| Hello World! |
+--+
#+END_SRC"

And, say, I'm writing a function for my exporter:

(defun org-myexporter-src-block (src-block contents info)
(let ((file (xxx yyy)

How can I get "images/hello-world.png" in org-myexporter-src-block?

Thanks,
-- 
yashi

Re: Release 9.5 tomorrow

[Yasushi SHOJI]

Hi Bastien,

It's not that important, but if you have time would you please take a
look at this:
https://list.orgmode.org/44f768b5-bade-e07a-29a7-15999eefd...@binghamton.edu/t/#mc90ae0a5266fe201d44e6f8f174b2d874f7c57fd

Thanks,
-- 
  yashi

On Tue, Sep 28, 2021 at 11:44 PM Bastien  wrote:
>
> Hi all,
>
> I'll release Org 9.5 tomorrow between 2pm and 3pm, Paris time.
>
> Feel free to email me at b...@gnu.org if there is an important bugfix
> (or a forgotten low-hanging patch) that needs to be committed.
>
> Thanks,
>
> --
>  Bastien
>

Re: Exporting: how to exclude top/bottom hline for tables?

[Yasushi SHOJI]

Hi,

On Thu, Sep 23, 2021 at 5:09 AM S Boucher  wrote:
>
> Is there a way to exclude the top and bottom hline of tables during export?

I don't see any option to change.  But you can do:

,
| (defun my/remove-bottom (borders)
|   (remove-if (lambda (x) (memq x '(bottom top above below))) borders))
| (advice-add 'org-export-table-cell-borders :filter-return #'my/remove-hlines)
`

tweak the list to change the behaviour.

> When I'm exporting to UTF-8, the top and bottom lines of the tables do not 
> display correctly for me.
>
> Though the number of chars is correct, the face used by emacs does not match 
> the face used for the rest of the file.

I guess fixing the faces is the right way forward.
-- 
 yashi

Re: Heading toward Org 9.5

[Yasushi SHOJI]

Hi Pankaj,

On Wed, Sep 22, 2021 at 5:21 PM Pankaj Jangid  wrote:
> Is there a page where I can see the changes when moving from 9.4 to
> 9.5.

Like etc/ORG-NEWS ?
http://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/etc/ORG-NEWS

You can see it on the web but it's much more present to use Org Mode
for obvious reasons.

Best,
-- 
   yashi

Re: publishing: no default publishing function, or symbol is not defined

[Yasushi SHOJI]

Hi,

I've also added a test case for the default translation function.
I'm not sure it's justified to add a new func `org-plist-delete-all`
just for this.
We can move the function to the test file if we don't need it in org-marcs.
-- 
yashi
From 2fdf67b4ddfac97acb2b685957b6e4ca26474fb4 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Sun, 19 Sep 2021 18:56:19 +0900
Subject: [PATCH 1/3] ox-publish: Set default transformation

As documented in Org Manual, we should have the default transformation
function set to org-html-publish-to-html.

Signed-off-by: Yasushi SHOJI 
---
 lisp/ox-publish.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index c25dd5473..99b1dca81 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -617,7 +617,8 @@ files, when entire projects are published (see
 			  (abbreviate-file-name filename
 	 (project-plist (cdr project))
 	 (publishing-function
-	  (pcase (org-publish-property :publishing-function project)
+	  (pcase (org-publish-property :publishing-function project
+   'org-html-publish-to-html)
 	(`nil (user-error "No publishing function chosen"))
 	((and f (pred listp)) f)
 	(f (list f
-- 
2.33.0

From 4978f588443f0ac27c75676697c2cc1b8beae668 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Mon, 20 Sep 2021 02:09:29 +0900
Subject: [PATCH 2/3] org-macs: Introduce org-plist-delete-all

In some cases we want to remove multiple properties from a plist.
This function just for that.

Signed-off-by: Yasushi SHOJI 
---
 lisp/org-macs.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 18ae642c7..bd4bb5066 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -538,6 +538,11 @@ that may remove elements by altering the list structure."
 (setq list (delete (pop elts) list)))
   list)
 
+(defun org-plist-delete-all (plist props)
+  "Delete all elements in PROPS from PLIST"
+  (dolist (e props plist)
+(setq plist (org-plist-delete plist e
+
 (defun org-plist-delete (plist property)
   "Delete PROPERTY from PLIST.
 This is in contrast to merely setting it to 0."
-- 
2.33.0

From 83913a2b0becb8429e9cc4e5872a9c7557351d03 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Mon, 20 Sep 2021 02:10:26 +0900
Subject: [PATCH 3/3] testing: ox-publish: Add a test case for default trans
 func

We use `org-html-publish-to-html' as the default transformation
function.  This commit adds a test case to make sure that org-publish
produces exact same output when org-html-publish-to-html is given as
:publishing-function or without it.

Because `org-publish-property' checks the given property with
`plist-member', we can't pass nil with :publishing-function; This
causes ox-publish to error out with "No publishing function chosen".

Thus we are removing :publishing-function from the plist using
`org-plist-delete-all'.

Signed-off-by: Yasushi SHOJI 
---
 testing/lisp/test-ox-publish.el | 36 -
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/testing/lisp/test-ox-publish.el b/testing/lisp/test-ox-publish.el
index 35031742f..3bfb985ab 100644
--- a/testing/lisp/test-ox-publish.el
+++ b/testing/lisp/test-ox-publish.el
@@ -22,12 +22,16 @@
 
 ;;; Helper functions
 
-(defun org-test-publish (properties handler)
+(defun org-test-publish (properties handler  remove-prop)
   "Publish a project defined by PROPERTIES.
 Call HANDLER with the publishing directory as its sole argument.
 Unless set otherwise in PROPERTIES, `:base-directory' is set to
 \"examples/pub/\" sub-directory from test directory and
-`:publishing-function' is set to `org-publish-attachment'."
+`:publishing-function' is set to `org-publish-attachment'.
+Because `org-publish-property' uses `plist-member' to check the
+existance of a property, a property with a value nil is different
+from non-existitance.  Properties in REMOVE-PROP will be remove
+from the final plist."
   (declare (indent 1))
   (let* ((org-publish-use-timestamps-flag nil)
 	 (org-publish-cache nil)
@@ -35,13 +39,15 @@ Unless set otherwise in PROPERTIES, `:base-directory' is set to
 	 (pub-dir (make-temp-file "org-test" t))
 	 (org-publish-timestamp-directory
 	  (expand-file-name ".org-timestamps/" pub-dir))
+ (props (org-plist-delete-all
+ (org-combine-plists
+  `(:base-directory ,base-dir
+:publishing-function org-publish-attachment)
+  properties
+  `(:publishing-directory ,pub-dir))
+ remove-prop))
 	 (project
-	  `("test" ,@(org-combine-plists
-		  `(:base-directory
-			,base-dir
-			:publishing-function org-publish-attachment)
-		  properties
-		  `(:publishing-directory ,pub-dir)
+	  `("test" ,@

Re: publishing: no default publishing function, or symbol is not defined

[Yasushi SHOJI]

Hi Chris,

On Sun, Jun 20, 2021 at 3:30 AM Christopher W. Ryan via General
discussions about Org-mode.  wrote:
> But is there not a default publishing action, that requires no explicit
> :publishing-function statement? This part of the documentation says
> there is:
>
> https://orgmode.org/manual/Publishing-action.html#Publishing-action

I just encountered the exact problem.  The attached patch fixed it for
me.  Would you mind testing it?

ps. I've dug a bit in the commit history but I couldn't find any evidence that
we've ever supported this default behaviour at least with the current exporter.

Nicolas, if that's true, should we change the documentation instead?

Best,
-- 
   yashi
From 2fdf67b4ddfac97acb2b685957b6e4ca26474fb4 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Sun, 19 Sep 2021 18:56:19 +0900
Subject: [PATCH] ox-publish: Set default transformation

As documented in Org Manual, we should have the default transformation
function set to org-html-publish-to-html.

Signed-off-by: Yasushi SHOJI 
---
 lisp/ox-publish.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index c25dd5473..99b1dca81 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -617,7 +617,8 @@ files, when entire projects are published (see
 			  (abbreviate-file-name filename
 	 (project-plist (cdr project))
 	 (publishing-function
-	  (pcase (org-publish-property :publishing-function project)
+	  (pcase (org-publish-property :publishing-function project
+   'org-html-publish-to-html)
 	(`nil (user-error "No publishing function chosen"))
 	((and f (pred listp)) f)
 	(f (list f
-- 
2.33.0

Git repository status

[Yasushi SHOJI]

Hi,

It seems like we are transitioning from code.orgmode.org to
git.savannah.gnu.org, but still not synced?

Which branch, gnu.org/main or orgmode.org/master, should I make patches against?

Best,
--
yashi

Re: ob-R: Error about longer than max-lines even with :result silent

[Yasushi SHOJI]

Hi Timothy,

On Tue, Aug 31, 2021 at 10:40 PM Timothy  wrote:
> Thanks for going to the effort to document this Yasushi. I’ve taken a look at
> your patches and they look quite good and straightforward to me. I’ve taken 
> the
> liberty of pushing them to master.

Thank you for taking your time for this. :-)  I really appreciate it.

Best,
-- 
   yashi

Re: ob-R: Error about longer than max-lines even with :result silent

[Yasushi SHOJI]

Hi Charles,

On Mon, Aug 16, 2021 at 3:04 AM Berry, Charles  wrote:
> > On Aug 15, 2021, at 6:19 AM, Yasushi SHOJI  wrote:
[...]
> > It seems like the following ECM cause an error:
> > Error (org-babel): Error reading results: (user-error "Region is
> > longer than ‘org-table-convert-region-max-lines’ (999) lines; not
> > converting")
> >
> > I assumed that with ":results silent" it shouldn't warn or error about
> > the output.  Is it expected or a bug?
> >
>
> This is expected per the `org-babel-insert-result' docstring.
>
> However, the documentation does not mention that `:results none' is an 
> option.  Is that what you want?

Yes, that's exactly what I was looking for.

I'm attaching patches to document it.  Nicolas, or anyone with commit
permission, if you find it useful please merge them.

Thanks,
-- 
  yashi


doc-ob-results-none.tar.gz
Description: application/gzip

ob-R: Error about longer than max-lines even with :result silent

[Yasushi SHOJI]

Hello,

It seems like the following ECM cause an error:
Error (org-babel): Error reading results: (user-error "Region is
longer than ‘org-table-convert-region-max-lines’ (999) lines; not
converting")

I assumed that with ":results silent" it shouldn't warn or error about
the output.  Is it expected or a bug?

,
| #+begin_src R :results silent
|   c(1:1000)
| #+end_src
`

Thanks,
-- 
   yashi

Re: org-cycle-internal-local unfold a plain list in parent

[Yasushi SHOJI]

Hi,

On Sat, Oct 3, 2020 at 7:55 PM Yasushi SHOJI  wrote:
> Move your cursor to the headline "second" and hit tab to cycle,
> then the list "foo" is also unfolded and you now see "bar"
> as well as the headline "third".  I was expecting to see only
> the "third".

I just run bisection on it and it shows me the following commit:

85ed1fd01dee462b59bcd622b3d0dee739d0214b is the first bad commit
commit 85ed1fd01dee462b59bcd622b3d0dee739d0214b
Author: Nicolas Goaziou 
Date:   Mon Dec 25 23:53:26 2017 +0100

Fix visibility cycling when point is invisible

* lisp/org.el (org-cycle-internal-local): Fix visibility cycling when
  point is invisible.

Reported-by: Ruy Exel 
<http://lists.gnu.org/r/emacs-orgmode/2017-12/msg00314.html>

 lisp/org.el | 1 +
 1 file changed, 1 insertion(+)

Does it ring a bell for anyone?
-- 
   yashi

org-cycle-internal-local unfold a plain list in parent

[Yasushi SHOJI]

Hi,

I see a plain list unfolded when I cycle a sub headline.

Say, I have the following org file:

#+begin_src org
  ,* first
- foo
  - bar
  ,** second
  ,*** third
#+end_src

Fold the list "foo" and the second headline, thus what you see
on your screen is more like:

* first
  - foo...
** second...

Move your cursor to the headline "second" and hit tab to cycle,
then the list "foo" is also unfolded and you now see "bar"
as well as the headline "third".  I was expecting to see only
the "third".

Is this expected behaviour?
Do I have some customizations on?

This is with release_9.4-43-g262bebb76 with Emacs 27.
-- 
   yashi

Re: Another case which org-insert-todo-heading doesn't work

[Yasushi SHOJI]

Hi,

On Thu, Mar 26, 2020 at 11:31 AM Kyle Meyer  wrote:
>
> > Does anyone see this?
>
> No, I tried on master (5b9698870) as well as maint (685b2c441) and
> didn't see the behavior you describe.  In both cases, an unchecked box
> is inserted.
>
> What Org version are you using?  Can you trigger the behavior without
> any customization?

I've tried both emacs 26 and 27 with -Q -q.

Org mode version 9.3.6 (release_9.3.6-441-gba6855 @
/home/yashi/src/org-mode/lisp/)
GNU Emacs 27.0.90 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0)
 of 2020-03-16
GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu) of 2019-04-14

What I did was to add org-mode/lisp to the load-path and load org.  That's it.
(add-to-list 'load-path "~/src/org-mode/lisp/")
-- 
yashi

Another case which org-insert-todo-heading doesn't work

[Yasushi SHOJI]

Hi,

https://www.mail-archive.com/emacs-orgmode@gnu.org//msg122319.html

There seems to be another case where org-insert-todo-heading doesn't
work.  Let's say we have the following doc.

#+begin_src org
  ,* foo
- [ ] a
  - [ ] b
#+end_src

If the list is unfolded, org-insert-todo-heading works everywhere. But
once you fold the list at "a" so that what we see is "- [ ] a...", the
function doesn't work but creates a next heading with "TODO" with it.

Does anyone see this?

#+begin_src org
  ,* foo
- [ ] a
  - [ ] b

  ,* TODO
#+end_src
-- 
   yashi

[O] shift dates in timestamp range

[Yasushi SHOJI]

Hi,

Is there a way to change both start and end date in timestamp range?
Given that the following timestamp range with `|` as the current cursor

CLOCK: [2019-02-2|2 Fri 12:00]--[2019-02-22 Fri 21:00] =>  9:00

I'd like to `S-Right` and get

CLOCK: [2019-02-2|3 Sat 12:00]--[2019-02-23 Sat 21:00] =>  9:00

I thought I saw the function somewhere but couldn't find it.

TIA,
-- 
  yashi

Re: [O] Clone tree backwards in time

[Yasushi SHOJI]

Hi Nicolas,

On Sat, Jan 19, 2019 at 2:56 AM Nicolas Goaziou  wrote:
> Yasushi SHOJI  writes:
>
> > Unfortunately, I don't have write permission to the repo.  So we need
> > to ask one of the maintainers to merge it.
>
> Sure. Could you also add an entry in ORG NEWS on that feature?

Done.

> Note you can also ask for write permission to Bastien, if you're
> interested.

If you don't mind reviewing my patches via email, I'm just OK without it.
-- 
  yashi
From 852385892a293e2a3479846a3f96e98678ba93d3 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Mon, 14 Jan 2019 10:19:50 +0900
Subject: [PATCH] org-clone: Allow time shift in backward

Make `org-clone-subtree-with-time-shift` accept a negative value to
shift the timestamp in backward.

Reported-by: Scott Randby 
<http://lists.gnu.org/r/emacs-orgmode/2019-01/msg00151.html>

Signed-off-by: Yasushi SHOJI 
---
 etc/ORG-NEWS |  5 +
 lisp/org.el  |  2 +-
 testing/lisp/test-org.el | 12 
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index e06d0c09b..4821cfa85 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -104,6 +104,11 @@ A 'native option was added to org-highlight-latex-and-related. It
 matches the same structures than 'latex but it calls
 org-src-font-lock-fontify-block instead, thus bringing about full
 LaTeX font locking.
+*** ~org-clone-subtree-with-time-shift~ learnt to shift backward in time
+== (~org-clone-subtree-with-time-shift~) now takes a
+negative value as a valid repeater to shift time stamps in backward
+in cloned subtrees.  You can give, for example, ‘-3d’ to shift three
+days in the past.
 
 ** New functions
 *** ~org-dynamic-block-insert-dblock~
diff --git a/lisp/org.el b/lisp/org.el
index 5c11de7b6..e71ba73e6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8452,7 +8452,7 @@ with the original repeater."
 		"")))			;No time shift
 	 (doshift
 	  (and (org-string-nw-p shift)
-	   (or (string-match "\\`[ \t]*\\+?\\([0-9]+\\)\\([dwmy]\\)[ \t]*\\'"
+	   (or (string-match "\\`[ \t]*\\([\\+\\-]?[0-9]+\\)\\([dwmy]\\)[ \t]*\\'"
  shift)
 		   (user-error "Invalid shift specification %s" shift)
 (goto-char end-of-tree)
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 976b7d8d6..db34a03c2 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1496,6 +1496,18 @@
 	(replace-regexp-in-string
 	 "\\( [.A-Za-z]+\\)\\( \\+[0-9][hdmwy]\\)?>" "" (buffer-string)
 	 nil nil 1
+  ;; Clone repeating once in backward.
+  (should
+   (equal "\
+* H1\n<2015-06-21>
+* H1\n<2015-06-19>
+* H1\n<2015-06-17 +1w>
+"
+	  (org-test-with-temp-text "* H1\n<2015-06-21 Sun +1w>"
+	(org-clone-subtree-with-time-shift 1 "-2d")
+	(replace-regexp-in-string
+	 "\\( [.A-Za-z]+\\)\\( \\+[0-9][hdmwy]\\)?>" "" (buffer-string)
+	 nil nil 1
   ;; Clone non-repeating zero times.
   (should
(equal "\
-- 
2.20.1

Re: [O] Clone tree backwards in time

[Yasushi SHOJI]

Hi,

Unfortunately, I don't have write permission to the repo.  So we need
to ask one of the maintainers to merge it.
I can put it in my personal github repo, if that helps.
-- 
 yashi

On Wed, Jan 16, 2019 at 4:05 AM Scott Randby  wrote:
>
> On 1/13/19 8:23 PM, Yasushi SHOJI wrote:
> > On Thu, Jan 10, 2019 at 1:28 PM Scott Randby  wrote:
> >> On occasion, I need to clone a tree backwards in time. I tried using 
> >> something like -2d (instead of the usual +2d) without success. Is there a 
> >> way to clone backwards in time?
> >
> > How about this?
>
> Unfortunately, I don't have the knowledge needed to test your patch, but it 
> seems good to me. Any possibility of testing this and maybe incorporating it 
> into Org?
>
> Scott
>

Re: [O] Clone tree backwards in time

[Yasushi SHOJI]

Hi,

On Thu, Jan 10, 2019 at 1:28 PM Scott Randby  wrote:
> On occasion, I need to clone a tree backwards in time. I tried using 
> something like -2d (instead of the usual +2d) without success. Is there a way 
> to clone backwards in time?

How about this?
-- 
yashi
From 5d421e09f80dde295bbd4541059f5d432dce2c59 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Mon, 14 Jan 2019 10:19:50 +0900
Subject: [PATCH] clone: Allow time shift in backward

Make org-clone-subtree-with-time-shift accept a negative value to
shift the timestamp in backward.
---
 lisp/org.el  |  2 +-
 testing/lisp/test-org.el | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 0b090ee39..19b1946a0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8451,7 +8451,7 @@ with the original repeater."
 		"")))			;No time shift
 	 (doshift
 	  (and (org-string-nw-p shift)
-	   (or (string-match "\\`[ \t]*\\+?\\([0-9]+\\)\\([dwmy]\\)[ \t]*\\'"
+	   (or (string-match "\\`[ \t]*\\([\\+\\-]?[0-9]+\\)\\([dwmy]\\)[ \t]*\\'"
  shift)
 		   (user-error "Invalid shift specification %s" shift)
 (goto-char end-of-tree)
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 976b7d8d6..db34a03c2 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -1496,6 +1496,18 @@
 	(replace-regexp-in-string
 	 "\\( [.A-Za-z]+\\)\\( \\+[0-9][hdmwy]\\)?>" "" (buffer-string)
 	 nil nil 1
+  ;; Clone repeating once in backward.
+  (should
+   (equal "\
+* H1\n<2015-06-21>
+* H1\n<2015-06-19>
+* H1\n<2015-06-17 +1w>
+"
+	  (org-test-with-temp-text "* H1\n<2015-06-21 Sun +1w>"
+	(org-clone-subtree-with-time-shift 1 "-2d")
+	(replace-regexp-in-string
+	 "\\( [.A-Za-z]+\\)\\( \\+[0-9][hdmwy]\\)?>" "" (buffer-string)
+	 nil nil 1
   ;; Clone non-repeating zero times.
   (should
(equal "\
-- 
2.20.1

Re: [O] Exporting description list without description

[Yasushi SHOJI]

Hi,

On Thu, Jan 3, 2019, 22:40 Eric S Fraga  wrote:

> yes, and I get the same as you do, but that whitespace difference should
> make no difference in the PDF result?  I guess it may make a difference
> for other export targets.
>

Yes.  I know some backends don't care.  I just couldn't find a reason why
and where in the element.el or ox.el.   if this isn't intended, should this
be fixed, perhaps?

Thanks,
-- 
  yashi

>

Re: [O] Exporting description list without description

[Yasushi SHOJI]

Hi,

On Wed, Jan 2, 2019 at 11:52 PM Eric S Fraga  wrote:
> What export target?  I don't see any difference when exporting to LaTeX.

Even Latex backed does it differently.  Note the space between one and two.
Here are both outputs:

\begin{description}
\item[{one}]

\item[{two}]
\end{description}

vs

\begin{description}
\item[{one}] This is 1
\item[{two}] This is 2
\end{description}

Does it happen on your env.? or is it just me?
-- 
yashi

[O] Exporting description list without description

[Yasushi SHOJI]

Hi,

I'm not sure this is a bug or something else.  But the following two
list behave differently when exported.  The fist one inserts a newline
between one and two.

Is there any reason to do that?  Yes, they are description list items
without description.  So there isn't much use but stil..

- one ::
- two ::

- one :: This is 1
- two :: This is 2

Thanks,
-- 
 yashi

Re: [O] Bug: org export to html add a unnecessary empty line in "example" block [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/local/Cellar/emacs-plus/26.1/share/emacs/26.1/lisp/org/)]

[Yasushi SHOJI]

Hi Nicolas,

Sorry to reply this old thread but...
Would you mind to apply this fix to the maint branch as well?

Thanks in advance.
-- 
 yashi

On Mon, Jul 2, 2018 at 7:32 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> 孙振祥  writes:
>
> > the org file like
> > : abc
> > : def
> >
> > and export to html will become
> > abc
> > def
> >
> > 
>
> Fixed. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] What's the canonical way to pass information within an Org exporter?

[Yasushi SHOJI]

Hi,

On Wed, Feb 7, 2018 at 8:35 AM, Kaushal Modi  wrote:
> I believe the info plist should be used ideally, but I cannot figure out how
> to tap in new information or update existing information in the `info'
> channel used throughout the exporter.

Some exporter does `plist-put`.
Is that what you are looking for?
-- 
  yashi

Re: [O] easy way to open include files

[Yasushi SHOJI]

On Thu, Feb 8, 2018 at 3:20 PM, Yasushi SHOJI <yasushi.sh...@gmail.com> wrote:
> Is there any function / key bindings to open a included file?

I don't know what I was up to.

The manual says:

C-c '
Visit the include file at point.

Sorry for the noise.
-- 
  yashi

[O] easy way to open include files

[Yasushi SHOJI]

Hi,

Is there any function / key bindings to open a included file?

Let's say we have a.org which has:

* headline

#+INCLUDE: |b.org

and we are at "|", which indicates a cursor position.
How can I easily open "b.org"?
-- 
  yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi,

On Sun, Feb 4, 2018 at 6:40 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>
>> Hmm... I'm using 4b2006db3d04, which includes b4cc12fc32a771 but
>> it still inf-loops.  `key-binding` returns `fill-paragraph`.  I tried
>> it `toggle-fill-unfill`,
>> which I set to `M-q` in general, and `org-fill-paragraph`, but nothing
>> works here.
>>
>> I see that `org-babel-do-in-edit-buffer` is a macro.  and my limited skill 
>> with
>> edebug doesn't reveal anything. :-<
>
> You may try to restart Emacs.

I did.  It inf-loops.  Does anyone else see this?  Is it just me?
Oh, well.  I'll try to debug when I have time.

BTW, I'm all for moving manual.org to the core.
I'm sorry I've hijacked the thread.
-- 
 yashi

Re: [O] exporting a big project in multiple files to both pdf and html

[Yasushi SHOJI]

Hi,

On Fri, Feb 2, 2018 at 4:41 PM, Alan Schmitt
 wrote:
>> What you want is to have multiple pdf files, say a.pdf and b.pdf, and link 
>> from
>> a.pdf to some specific page on the b.pdf, right?
>
> No, I want multiple html files and a single pdf file generated from
> multiple org files. It seems the simplest solution is to call a function
> that fixes the links for the pdf export. I'll report here once I have
> that function.

https://github.com/yashi/multi-html-single-pdf

I have to use macro expansion and `org-export-global-macros` to swap the link.
I don't think we have conditionals to switch an internal and an external link.

HTML outputs are still not good at all (wrong chapter number, excess toc, etc.),
but at least you can see the body of the text.
-- 
   yashi

Re: [O] org-mode source code repo make error

[Yasushi SHOJI]

Hi,

On Fri, Feb 2, 2018 at 10:24 AM, numbch...@gmail.com
 wrote:
> When I try to compile with command `make`, but got this output:
[...]
> make -C lisp compile

just do `make compile`.

you can't use `-C` in org-mode source tree.
In my case with `-C`, I get:

$ make -C lisp compile
make: Entering directory '/home/yashi/src/org-mode/lisp'
Makefile:4: *** This make needs to be started as a sub-make from the
toplevel directory..  Stop.
make: Leaving directory '/home/yashi/src/org-mode/lisp'

$ git describe
release_9.1.6-419-g4b2006db3


`make help` for more option.
-- 
   yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi,

On Thu, Feb 1, 2018 at 11:55 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>
>> What if _I_, for my own project, want to customize the formatter and like to
>> call fill-paragraph, can I still do this?
>
> No need to tweak the formatter. You can post-process its output to your
> liking, e.g., with `org-fill-paragraph' called on the whole buffer.

Thanks.  That's what I did and found this bug.

>> BTW, while reading `org-fill-paragraph`, I found a bug.
>>
>> #+begin_src emacs-lisp
>>   (add-to-list 'load-path "~/path/to/orgdir/lisp")
>> #+end_src
>>
>> activate the region for the src block above, and do `M-x org-fill-paragraph`.
>> It will inf-loop because `M-q` moves the cursor back to the beginning of
>> the middle line.
>
> Fixed. Thank you.

Hmm... I'm using 4b2006db3d04, which includes b4cc12fc32a771 but
it still inf-loops.  `key-binding` returns `fill-paragraph`.  I tried
it `toggle-fill-unfill`,
which I set to `M-q` in general, and `org-fill-paragraph`, but nothing
works here.

I see that `org-babel-do-in-edit-buffer` is a macro.  and my limited skill with
edebug doesn't reveal anything. :-<

Thanks,
-- 
   yashi

Re: [O] exporting a big project in multiple files to both pdf and html

[Yasushi SHOJI]

Hi,

On Thu, Feb 1, 2018 at 9:29 PM, Alan Schmitt
 wrote:
> Not here. If I try to export the second file (the one with the link to
> the first file), I get an error:
>
> user-error: Unable to resolve link: "*A headline"

I now see that I totally misread your message.

What you want is to have multiple pdf files, say a.pdf and b.pdf, and link from
a.pdf to some specific page on the b.pdf, right?

I thought you want to generate one pdf from multiple org files.
Since you said "generate a single book from it".

Anyway, I don't know anything about latex, but how do you write such a
link in latex?

Something like this?: https://tex.stackexchange.com/q/41539
-- 
  yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

On Thu, Feb 1, 2018 at 8:43 PM, Yasushi SHOJI <yasushi.sh...@gmail.com> wrote:
> On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
> <m...@nicolasgoaziou.fr> wrote:
>> Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>>
>>> Do you see this on your env?  Or, is it just me?
>>
>> I don't see anything like this.
>
> Hmm... I don't know how to fix this.

I mean, I run `emacs -q`,
eval only the following code in the `*scratch*` buffer,
open `manual.org` and do `M-x org-reformat`.

and I see:

 >8  >8 
@@ -134,9 +133,9 @@
 You can clone Org's repository and install Org like this:

 #+begin_example
-  $ cd ~/src/
-  $ git clone g...@code.orgmode.org:bzg/org-mode.git
-  $ make autoloads
+$ cd ~/src/
+$ git clone g...@code.orgmode.org:bzg/org-mode.git
+$ make autoloads
 #+end_example

 Note that in this case, ~make autoloads~ is mandatory: it defines
 >8  >8 

I checked `org-src-preserve-indentation` is nil and
org-edit-src-content-indentation is 2.
I even `list-load-path-shadows` and check that git version of org is used.

What am I missing?


(add-to-list 'load-path "~/src/org-mode/lisp")
(defun org-reformat ()
(interactive)
(let ((result
   (benchmark-run 1
 (let ((document (org-element-interpret-data
(org-element-parse-buffer
   (erase-buffer)
   (insert document)
   (goto-char (point-min))
  (if (zerop (nth 1 result))
  (message "Org Re-format took %.2f seconds" (car result))
(message "Org Re-format took %.2f second (%.2fs in %d GCs)"
 (car result)
 (nth 2 result)
 (nth 1 result)
-- 
  yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi,

On Mon, Jan 29, 2018 at 11:41 PM, Nicolas Goaziou
<m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>
>> Do you see this on your env?  Or, is it just me?
>
> I don't see anything like this.

Hmm... I don't know how to fix this.

>> I'd like to have the formatter and `fill-paragraph` work in a coherent way.
>> But, if you, who know org much better than me, don't know, I don't think
>> I can help.  Though, just in case, can you elaborate a bit?
>
> The formatter doesn't call `fill-paragraph' at all. No wonder both do
> not work in a way you would expect.

ah, ok.

> The newline characters introduced in the output of the formatter were
> present already in the original text. However, some objects ignore white
> spaces on purpose. For example, [[foo bar]] and [[foo bar]] and [[foo\n
> bar]] are equivalent, so the parser does not retain the distinction
> between them. Hence links are always formatted on a single line.

I see.

> Now, I'm not sure the formatter should call `fill-paragraph', for some
> reasons:
>
> - the original document could be using `visual-line-mode' so there's
>   could be nothing to fill without Org knowing about it;
>
> - Calling `fill-paragraph' requires full fontification, so `org-mode'
>   would be initialised at every paragraph to fill;
>
> - `fill-paragraph' depends heavily on user's configuration (custom link
>   types, `org-fontify-emphasized-text', `org-hide-emphasis-markers',
>   `org-pretty-entities'...) whereas the formatter is expected to be more
>   neutral.

Being neutral is good.

What if _I_, for my own project, want to customize the formatter and like to
call fill-paragraph, can I still do this?

I don't know how `fill-paragraph` works and the second point you listed
above worries me.

With my ignorance, I thought just call org-fill-paragraph. Or, do you
mean that "`org-mode' will be initialized" in `org-fill-paragraph`?

BTW, while reading `org-fill-paragraph`, I found a bug.

#+begin_src emacs-lisp
  (add-to-list 'load-path "~/path/to/orgdir/lisp")
#+end_src

activate the region for the src block above, and do `M-x org-fill-paragraph`.
It will inf-loop because `M-q` moves the cursor back to the beginning of
the middle line.

> We could however, un-fill everything. But the output would be very
> different. So, TRTD is not obvious.

For the default behavior, I don't think that a good idea.

>> Since you fixed the big ones, I can see another issue.  This is also 
>> indentation
>> issue, but with a macro replacement .  Somehow, macro replacement
>> gets extra indentation.  Like this:
>
>>   a numeric prefix, check that many days.  For example, {{{kbd(C-1
>> - C-c / d)}}} shows all deadlines due tomorrow.
>> +  C-c / d)}}} shows all deadlines due tomorrow.
>
> This is related to the explanation above. Macros did the opposite of
> links. The parser didn't remove meaningless spaces upon parsing macros.
> So those would be inserted twice. I fixed this. Now macros show the same
> behaviour as links: even multi-lines macros are inserted as a single
> line.

Thank you for fixing this, too.
-- 
yashi

Re: [O] exporting a big project in multiple files to both pdf and html

[Yasushi SHOJI]

Hi,

On Thu, Feb 1, 2018 at 5:45 PM, Alan Schmitt
<alan.schm...@polytechnique.org> wrote:
> On 2018-02-01 11:17, Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>> On Fri, Jan 26, 2018 at 2:37 AM, Alan Schmitt
>> <alan.schm...@polytechnique.org> wrote:
>>> My question is about pdf export. Is it possible to take a document made
>>> of multiple org files and generate a single book from it? I'm worried
>>> that if I use a master org file that includes the other ones, the links
>>> between chapters would break.
>>
>> You can just use '#+INCLUDE' construct and Org will take care.
>
> My problem is links. To give a concrete example, here is the file I want
> to split in two:
>
> * A headline
>   :PROPERTIES:
>   :CUSTOM_ID: head1
>   :END:
>
> This is the first file.
>
> * Second headline
>
> The first headline is number [[#head1]]
>
>
> How do I change the link in the second headline so that I can split the
> second headline into its own file and export it by itself?

Using [[*A headline]] ?

I might be still missing something but I got following:

$ cat a.org
* A headline

This is the first file.

#+INCLUDE: b.org :minlevel 1

$ cat b.org
* Second headline

The first headline is number [[*A headline]]

$ org-export.sh a.org
$ cat a.tex
% Created 2018-02-01 Thu 20:08
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Yasushi SHOJI}
\date{\today}
\title{}
\hypersetup{
 pdfauthor={Yasushi SHOJI},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 26.0.91 (Org mode 9.1.6)},
 pdflang={English}}
\begin{document}

\tableofcontents

\section{A headline}
\label{sec:org0ac96d1}

This is the first file.

\section{Second headline}
\label{sec:org2092415}

The first headline is number \ref{sec:org0ac96d1}
\end{document}


hmm... latex export will generate \ref{sec:\#head}
if you have CUSTOM_ID set.  html exporter works, though.

Is it a bug?
-- 
  yashi

Re: [O] setting flags in python src blocks?

[Yasushi SHOJI]

Hi,

On Thu, Feb 1, 2018 at 8:47 AM, John Kitchin  wrote:
> Is it possible to set command line flags for an executable in src blocks? I
> was thinking of something like this
>
> #+BEGIN_SRC python :flags --some_flag=True :tangle test.py
> import app
>
> print(app.FLAGS.some_flag) # -> True
> #+END_SRC

ob-python doesn't suport :flags nor :cmdline, but you can set interpreter
with :python. So, you can do

#+begin_src python :python "python --some_flag=True"

to pass parameter to the interpreter.
-- 
   yashi

Re: [O] exporting a big project in multiple files to both pdf and html

[Yasushi SHOJI]

Hi,

On Fri, Jan 26, 2018 at 2:37 AM, Alan Schmitt
 wrote:
> I'm working on a project that is becoming too big to manage as a single
> file, so I'm looking at splitting it in several files. This would also
> have the benefit of generating several smaller html pages instead of a
> single huge one.

Does Org support this? or do you just export each file?

> My question is about pdf export. Is it possible to take a document made
> of multiple org files and generate a single book from it? I'm worried
> that if I use a master org file that includes the other ones, the links
> between chapters would break.

You can just use '#+INCLUDE' construct and Org will take care.
But that will break your follow of exporting html files described above.

How about having two master files, one for html and one for pdf.
In the html-master.org, you use links to connect.  And
in the pdf-master.org, you can just #+INCLUDE your files.

It'd be nice if we could tell exporters that we want multiple files from one
org file.

BTW, I don't think we have direct pdf exporter.  So, you must be talking about
the latex exporter, right?
-- 
   yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi,

On Mon, Jan 29, 2018 at 12:17 AM, Nicolas Goaziou
<m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>
>> A big one seems to be the indentation of description lists.
>> The formatter seems to prefer aligning the begging of a description
>> to the begging of a term.  But manual.org has some indentation.
>
> Somewhat fixed. The indentation of description items is weird.

I confirm that.

Thank you, always, for your great work!

>> The other big one is indentation of begin_example.  I'm not sure
>> this one is my setting or not.
>
> Have you set `org-src-preserve-indentation' or
> `org-edit-src-content-indentation'?

Nop.

`org-src-preserve-indentation'  is nil.
`org-edit-src-content-indentation' is 2.

But, formatter still align the contents to 0.

Do you see this on your env?  Or, is it just me?

>> Some minor diff is caused by links.  The formatter doesn't fold a
>> paragraph when link is at the end of the line. That is, if a paragraph
>> has a [[link like this]], the line goes on and on till the next fold
>> point.
>
> Not sure how to fix this, or even if that should be fixed.

I'd like to have the formatter and `fill-paragraph` work in a coherent way.
But, if you, who know org much better than me, don't know, I don't think
I can help.  Though, just in case, can you elaborate a bit?


Since you fixed the big ones, I can see another issue.  This is also indentation
issue, but with a macro replacement .  Somehow, macro replacement
gets extra indentation.  Like this:

@@ -6226,7 +6200,7 @@ schedule an item:[fn:65]
  or which will become due within ~org-deadline-warning-days~.
  With {{{kbd(C-u)}}} prefix, show all deadlines in the file.  With
  a numeric prefix, check that many days.  For example, {{{kbd(C-1
- C-c / d)}}} shows all deadlines due tomorrow.
+  C-c / d)}}} shows all deadlines due tomorrow.
-- 
 yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi Nicolas,

On Fri, Jan 26, 2018 at 7:32 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <yasushi.sh...@gmail.com> writes:
>
>> Also, the code converts all lower case "#+title",  "+begin_src" and
>> other "#+"s to
>> the UPCASE.  Is this intended?  I thought we are moving away from CAP
>> to lower?
>
> This was changed a few days ago. See commit
> 13424336a6f30c50952d291e7a82906c1210daf0.

Thanks.  I pulled the head and read that.

I still see quite a lot of changes when I reformat the
manual.org.

A big one seems to be the indentation of description lists.
The formatter seems to prefer aligning the begging of a description
to the begging of a term.  But manual.org has some indentation.

The other big one is indentation of begin_example.  I'm not sure
this one is my setting or not.

Some minor diff is caused by links.  The formatter doesn't fold a
paragraph when link is at the end of the line. That is, if a paragraph
has a [[link like this]], the line goes on and on till the next fold
point.
-- 
 yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi Nicolas,

On Wed, Jan 24, 2018 at 8:28 PM, Nicolas Goaziou  wrote:
> Org Lint is not a formatter. It detects common mistakes or hypothetical
> mistakes in an Org document, e.g., invalid links. In particular, it
> doesn't detect stylistic issues like those discussed above.

Oh, OK.

> It doesn't mean we couldn't run it automatically. However, it also emits
> warnings (see `trust' property) on perfectly valid syntax.
>
> As a side note, writing an Org formatter is trivial:
>
> (when (yes-or-no-p "Really format current buffer ? ")
>   (let ((document (org-element-interpret-data 
> (org-element-parse-buffer
> (erase-buffer)
> (insert document)
> (goto-char (point-min

You know, this is a mind-blowing.  Org already has everything it needs ;-)

Anyway, I tried the code and it took 2.4 second to reformat the whole document
on my i5-3360M 2.80GHz CPU.  It's a bit long for every commit, i guess.
But, could be installed on received hook, perhaps?

Also, the code converts all lower case "#+title",  "+begin_src" and
other "#+"s to
the UPCASE.  Is this intended?  I thought we are moving away from CAP to lower?
-- 
 yashi

Re: [O] [RFC] Moving "manual.org" into core

[Yasushi SHOJI]

Hi,

On Mon, Jan 22, 2018 at 10:54 PM, Rasmus  wrote:
> Bastien Guerry  writes:
>
>> I'm all for editing manual.org instead of org.texi in the long run.
>>
>> Before moving manual.org into doc/, I'd suggest we agree on editing
>> variables like `fill-column' and the like:
>>
>> fill-column: 70
>> org-list-description-max-indent: 5
>> org-edit-src-content-indentation: ?
>> org-src-preserve-indentation: ?
>>
>> This is necessary so that contributors don't mess up accidentally with
>> the desired format.
>
> Could we use .dir-locals.el to ensure that the correct settings are
> loaded?

How about using org-lint or some other formatter on git commit hook?
after go lang introduced gofmt, many projects adapted the method to
keep the code constant.

too much / slow?
-- 
  yashi

Re: [O] [RFC] Dog food, anyone?

[Yasushi SHOJI]

Hi,

On Sat, Dec 23, 2017 at 11:12 PM, Kaushal Modi  wrote:
> The only minor issue is that it loads the whole manual as a single HTML
> page, so it takes a while to load. Do you know if there's a way to set it up
> so that it shows a single page per node as orgmode.org does?

I've looked around the doc but not sure how.  They support multi-files with
index, so it might be that we need to export to multi rst files?

Does org support such an export option?
-- 
   yashi

Re: [O] [RFC] Dog food, anyone?

[Yasushi SHOJI]

Hi Nicolas,

On Sun, Dec 17, 2017 at 7:34 PM, Nicolas Goaziou  wrote:
> The task started by Thomas S. Dye a couple years ago is now complete.
> The "manual.org" file in "contrib/" directory is an up-to-date,
> sometimes enhanced, version of the Org manual. Org can now eat its own
> dog food.

This is at great news!!

I remember a thread on the emacs-devel saying that texinfo html exporter doesn't
render as cute as the current standard (whatever that is).
But now we have the manual in org, and we can convert it to many format.

I just tried rst exporter, which I just happen to be using, and it works great,
with the following tiny patch. And the results is this.

http://org-manual.readthedocs.io/en/latest/

Info and orgmode.org/org.html is already super useful so this doesn't
gain much for me.  but someone might like the way it renders.

regards,
-- 
   yashi (now on to fix my own exporters ;-p)

--- ox-rst.el~ 2017-11-22 21:01:58.503667382 +0900
+++ ox-rst.el 2017-11-22 21:52:31.213331562 +0900
@@ -1086,7 +1086,7 @@
   ;; Protect ..
   (setq text (replace-regexp-in-string "^[\s-]*\\.\\. [^\\[]" ".. " text))
   ;; Protect ^\d+.
-  (setq text (replace-regexp-in-string "^\\([[:digit:]]\\)+\\." "\\1\\." text))
+  (setq text (replace-regexp-in-string "^\\([[:digit:]]\\)+\\."
"\\1." text))
   ;; Return value.
   text)

Re: [O] possible to store a link to a specific entry in the *texinfo* file?

[Yasushi SHOJI]

Hi,

On Wed, Dec 20, 2017 at 11:57 PM, Shiyao MA  wrote:
> Is it possible to specify an exact match?
>
>  [[info:elisp#define-minor-mode]] gives two potential matches.

Not that I know of.  The behavior is of Info-index and I don't think
it can do that.
Unless, of cause, you change the function to handle only the exact matches.

regards,
-- 
 yashi

Re: [O] possible to store a link to a specific entry in the *texinfo* file?

[Yasushi SHOJI]

Hi,

I'm sorry that I miss read your question.

No, org-store-link, or org-info-store-link to be precise, doesn't support
storing the index you just used or you are on.

I'm not sure how to figure out what a user is trying to store is either
the current node or the index.


You can, however, write a link by hand

[[info:elisp#define-minor-mode]]

and org is happy to open and jump to the entry
pointed by the index.

regards,
-- 
yashi

Re: [O] possible to store a link to a specific entry in the *texinfo* file?

[Yasushi SHOJI]

Hi,

On Tue, Dec 19, 2017 at 9:57 AM, Shiyao MA  wrote:
> However, org-store-link stores to the node : Stored:
> info:elisp#Defining Minor Modes
> Instead of the exact entry.

I'm not sure what version of Org mode you are using but
at least Org 8.3 supports info index as well as info node in
the same format.

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=96e1971f0fac6db1ac133faab0f7ed3bc38d96e7
-- 
   yashi

Re: [O] How to generate clock report for hours worked each day?

[Yasushi SHOJI]

Hi,

On Wed, Sep 27, 2017 at 3:27 AM, ConcreteVitamin
 wrote:
> Following up on this: is there a way to configure such that non-clocked in
> files (0:00) are not shown in this table?

:fileskip0 t

?
-- 
 yashi

Re: [O] mimetype for orgmode files

[Yasushi SHOJI]

Hi,

There is RFC 6648, which "deprecating the "X-" Prefix".

So, it might be better to use "text/org".

https://tools.ietf.org/html/rfc6648
-- 
   yashi

Re: [O] Scatter-gather idea

[Yasushi SHOJI]

Hi Bob,

On Mon, Apr 3, 2017 at 1:34 PM, Bob Newell  wrote:
>
> A simple use case: you're brainstorming, making org-mode headline
> entries as fast as you can think or type. After a while you notice that
> a number of entries seem to be related and might actually be better
> considered as a spin-off. So you want to gather up all of those entries
> and send them off in bulk to a different org file.

mark them with tags, and do org-tags-view.  Or, you can use regex or other
criteria if you like.

If you want to refile them to a org file, mark entries you want to refile
with
org-agenda-bulk-mark and do org-agenda-bulk-action and 'r' to select
a file.

http://orgmode.org/manual/Agenda-commands.html#Agenda-commands
--
   yashi

Re: [O] Bug: Updating clocktable hides other content [9.0.5 (9.0.5-elpa @ /home/christof/.emacs.d/elpa/org-20170210/)]

[Yasushi SHOJI]

Hi Christof,

On Sun, Mar 26, 2017 at 7:37 AM, Christof Musik 
wrote:
>
> I have noticed some problems on updating a clocktable in a dynamic block.
> If you update this table with org-dblock-update, then all content besides
that table
> is hidden. I have not found a way to show it again without opening the
file again.

It's a bug with :scope subtree.  I had noticed this before but haven't come
to fix it.

You can just widen the buffer with C-x n w, or M-x widen.
-- 
  yashi

[O] [PATCH] org-clock: Align formula column in clock tables

[Yasushi SHOJI]

* lisp/org-clock.el (org-clocktable-write-default): Align formula
  column in clock tables.

  Here is an ECM:

  * foo
  ** sub
 :LOGBOOK:
 CLOCK: [2017-03-18 Sat 15:00]--[2017-03-18 Sat 15:15] =>  0:15
 :END:
  ** sub2
 :LOGBOOK:
 CLOCK: [2017-03-18 Sat 15:15]--[2017-03-18 Sat 15:30] =>  0:15
 :END:
  ** sub3
  *** subsub1
  :LOGBOOK:
  CLOCK: [2017-03-18 Sat 13:00]--[2017-03-18 Sat 13:15] =>  0:15
  :END:
  *** subsub1
  :LOGBOOK:
  CLOCK: [2017-03-18 Sat 14:00]--[2017-03-18 Sat 14:15] =>  0:15
  :END:
  * bar
:LOGBOOK:
CLOCK: [2017-03-18 Sat 13:15]--[2017-03-18 Sat 13:30] =>  0:15
:END:
  * table
  #+BEGIN: clocktable :maxlevel 3 :scope file :formula %
  #+CAPTION: Clock summary at [2017-03-18 Sat 16:50]
  | Headline  |   Time |  |  | % |
  |---++--+--+---|
  | *Total time*  | *1:15* |  |  | 100.0 |
  |---++--+--+---|
  | foo   |   1:00 |  |  |  80.0 |
  | \_  sub   || 0:15 |  |  20.0 |
  | \_  sub2  || 0:15 |  |  20.0 |
  | \_  sub3  || 0:30 |  |  40.0 |
  | \_subsub1 ||  | 0:15 |  20.0 |
  | \_subsub1 ||  | 0:15 |  20.0 |
  | bar   |   0:15 |  |  |  20.0 |
  #+END:
---
 lisp/org-clock.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index ffa1b3003..73afd87e6 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2622,6 +2622,7 @@ from the dynamic block definition."
 ;; Empty fields for higher levels.
 (make-string (max 0 (1- (min time-columns level))) ?|)
 hlc (org-minutes-to-clocksum-string time) hlc "|" ; time
+(make-string (max 0 (- time-columns level)) ?|)
 (if (eq formula '%)
 (format "%.1f |" (* 100 (/ time (float total-time
   "")
-- 
2.11.0

Re: [O] limitation for macro expansion

[Yasushi SHOJI]

Hi Nicolas,

Thank you for your time.  I really appreciate it.

On Tue, 07 Mar 2017 01:41:34 +0900,
Nicolas Goaziou wrote:
>
> Yasushi SHOJI <ya...@atmark-techno.com> writes:
>
> > I assume that the key phrase is "anywhere Org markup is recognized".
> > Link format doesn't allow Org markup, right?
>
> Not in the first part indeed. You can, however, use a macro in the
> description part of the link.

OK.

> > # I use file_name_with_underscore.txt more than subscripts
> > # I'd be nice, at least for me, to have '\sub' and '\super' special keywords
> > # but leave the underscores alone.
>
> I don't understand where you need this. At the export level, you can use
> `org-export-with-sub-superscripts' to `{}'. At display level, you can do
> the same with `org-use-sub-superscripts'.

I hate to waste your precious time because of my ignorant and I can
live with '\under' but I'm totally lost.

Are you saying that it's possible to generate "a_20170307.txt" from
"a_{{{timestamp}}}.txt" if I set those variables mentioned above
correctly? without using '\under'?

I know you said it's ambiguous.  So let me clarify what I said. What I
said above was to change the syntax (or lex / parser's behavior) when
some variable, let's say 'org-do-not-parse-sub-superscripts', is set
to nil.

So that a) org leaves '_' in "a_{{{somemacro}}}" as-is and the macro
parser will pickup the "{{{somemacro}}}, b) when I want to use
subscript, I can write "a\sub{someword or two}" to make a subscript.

People like me don't use subscript much (to be honest, I've never
wanted to use subscript since I started use Org, seven years?), but
use '_' many times in a doc.  Hence, (setq org-use-sub-superscripts
nil) in my init.el.  But for someone wanting to use subscripts in rare
occasion, '\sub' would serve.

I can understand if you say it's not good idea to change the _syntax_
by a variable.

> > hmm.  just checked the source.  org-use-sub-superscripts is only for 
> > display.
> > org-export-with-sub-superscripts is just for exports.
>
> See above.
>
> > I was gonna just by-pass or disable subscript parser all together when
> > org-use-sub-superscripts is nil but it doesn't seems to be a good
> > idea, does it?
>
> This is exactly what a nil `org-export-with-sub-superscripts' does.

If that's the case, why doesn't macro parser pickup the
"{{{timestamp}}}" in "a_{{{timestamp}}}"?

Maybe this is my confusing point?  The component resposible defining
the org "syntax" is different from the parser?  Even if sub/super
parser is by-passed, because the "syntax" is subscript, the macro
parser won't be called on this substring?

Is the syntax defined in org-element--object-regexp and
org-element--object-lex?

Thanks,
--
   yashi

Re: [O] limitation for macro expansion

[Yasushi SHOJI]

Hi Nicolas,

On Mon, Mar 6, 2017 at 5:22 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Yasushi SHOJI <ya...@atmark-techno.com> writes:
> there are two ways to interpret it: the one you expect and
>
>   a_{CONTENTS} where CONTENTS is {{something}}.
>
> Since subscript syntax started first, it has precedence over the macro.

Yes.  That's what I understand from your response.  Thanks!

>> Doesn't seems to work.  When I export 'a_author', it
>> generates:
>>
>>   a_{Yasushi SHOJI}
>>
>> I was expecting to see:
>>
>>   a_Yasushi SHOJI
>
> This is correct if you use `ascii' back-end.

Sorry for the confusion.
I just thought that you gave me a way to use macro with underscore.

>> Would it be OK to say that it's a design decision to ignore the macro
>> expansion in the link field at export time?
>
> It is. Actually, macros are not allowed in many places, as a design
> decision. See
>
>   (info "(org) Macro replacement")
>
> for more details.

I assume that the key phrase is "anywhere Org markup is recognized".
Link format doesn't allow Org markup, right?

>> ie)
>>
>>   #+MACRO: timestamp {{{date(%Y%m%d)}}}
>>
>>   Please open log_{{{timestamp}}}.txt
>>
>> Would it be possible for org to do this?
>
> You could try
>
>   #+MACRO: timestamp {{{time(%Y%m%d)}}}
>
>   Please open log\under{}{{{timestamp()}}}.txt

Ah!  Great idea.  That's what I'm looking for. Thanks.

# I use file_name_with_underscore.txt more than subscripts
# I'd be nice, at least for me, to have '\sub' and '\super' special keywords
# but leave the underscores alone.

>> If not, would it be possible for me to modify the code to achieve this?
>> My stupid idea is to:
>>
>>   - disable sub / superscript parser when org-use-sub-superscripts is nil
>
> See `org-export-with-sub-superscripts'.

hmm.  just checked the source.  org-use-sub-superscripts is only for display.
org-export-with-sub-superscripts is just for exports.

I was gonna just by-pass or disable subscript parser all together when
org-use-sub-superscripts is nil but it doesn't seems to be a good idea, does it?

>>   - reverse the precedence order of subscript and macro
>
> This would only move the problem elsewhere.

True.
-- 
 yashi

Re: [O] limitation for macro expansion

[Yasushi SHOJI]

Hi Nicolas,

On Sun, 05 Mar 2017 19:58:43 +0900,
Nicolas Goaziou wrote:
> 
> Yasushi SHOJI <ya...@atmark-techno.com> writes:
> > * test
> > - It works with chars around like this: Aa{{{author}}}bB.
> > - It works with numbers around like this: 12{{{author}}}34.
> > - It works with _ around like this: _{{{author}}}_.
> > - It works with =__= around like this: __{{{author}}}__.
> > - But it doesn't work with 'a_' prefixed like this: a_{{{author}}}.
> > - But it doesn't work with '1_' prefixed like this: 1_{{{author}}}.
> 
> The two examples above are ambiguous.

Ah, you mean the parser is unable to distinguish the macro and
subscript?  I didn't notice it since I've been disabled sub /
superscript feature all together.  In my configuration it seemed that
Org is silently ignoring the macro expansion.  Thank you for letting
me know!

> You should use author.

Doesn't seems to work.  When I export 'a_author', it
generates:

  a_{Yasushi SHOJI}

I was expecting to see:

  a_Yasushi SHOJI

> > - Link doesn't work like this: [[file:{{{input-file}}}][Bad link]]
> 
> Indeed. This kind of link is not supported as you cannot follow it
> (macros are an export-only feature).

Hmm, that's true that you can't follow it.

Would it be OK to say that it's a design decision to ignore the macro
expansion in the link field at export time?

> Feel free to provide a documentation patch if you think this needs to be
> made explicit.

Will do once I fully understand.

Now, what I'm trying to achieve with a macro is to generate a
filename-like string with a timestamp in it in my doc.

ie)

  #+MACRO: timestamp {{{date(%Y%m%d)}}}

  Please open log_{{{timestamp}}}.txt

Would it be possible for org to do this?


If not, would it be possible for me to modify the code to achieve this?
My stupid idea is to:

  - disable sub / superscript parser when org-use-sub-superscripts is nil
  - reverse the precedence order of subscript and macro

I know parsers are in org-element.el but not sure how the precedence
is decided.  If someone pointing at where to look, I'm very
appreciated.

Thanks,
-- 
   yashi

[O] limitation for macro expansion

[Yasushi SHOJI]

Hi,

I'm can't expand macro with prefix.  Is there any limitation for macro
expansion listed in the doc?

* test
- It works with chars around like this: Aa{{{author}}}bB.
- It works with numbers around like this: 12{{{author}}}34.
- It works with _ around like this: _{{{author}}}_.
- It works with =__= around like this: __{{{author}}}__.
- But it doesn't work with 'a_' prefixed like this: a_{{{author}}}.
- But it doesn't work with '1_' prefixed like this: 1_{{{author}}}.
- Link doesn't work like this: [[file:{{{input-file}}}][Bad link]]

Thanks,
--
  yashi

Re: [O] DEADLINE: position in entry

[Yasushi SHOJI]

Hi Nicolas,

On Fri, 25 Nov 2016 20:24:31 +0900,
Nicolas Goaziou wrote:
> 
> I cannot reproduce your problem? Could you try with -Q (and a minimal
> Org configuration)?

Hmm... That's what I did and got the following:

Week-agenda (W48):
Monday 28 November 2016 W48
  a:  DONE org
Tuesday29 November 2016
  a:  DONE org  
Wednesday  30 November 2016 
  a:  DONE org

Let me try again.

$ cd ~/src/org-mode
$ git describe
release_9.0.1-74-g3d80b35
$ make clean autoloads
$ ~/src/emacs25/src/emacs -Q -l /tmp/a.el -f 'org-agenda'

now I get

Week-agenda (W48):
Monday 28 November 2016 W48
Tuesday29 November 2016
  a:  DONE org
Wednesday  30 November 2016
Thursday1 December 2016
Friday  2 December 2016
Saturday3 December 2016
Sunday  4 December 2016

the commit 4b99ed5e seems to change the output a bit.  But I still get
the done entry.

I'm attaching those two files (just in case) but the contents are:

/tmp/a.el:
(add-to-list 'load-path "~/src/org-mode/lisp")
(setq org-agenda-files '("/tmp/a.org"))

/tmp/a.org:
* DONE org
  DEADLINE: [2016-01-07 Thu 17:39]

  SCHEDULED: <2015-09-29 Tue .+1w>

BTW, I'm on "GNU Emacs 25.1.90.1 (x86_64-pc-linux-gnu) of 2016-11-29", if it 
mutters.

$ cd ~/src/emacs25
$ git describe
emacs-24.5-rc3-fixed-8534-gf6da597

Let me know if you need any other info.

Thanks,
-- 
yashi
(add-to-list 'load-path "~/src/org-mode/lisp")
(setq org-agenda-files '("/tmp/a.org"))
* DONE org
  DEADLINE: [2016-01-07 Thu 17:39]

  SCHEDULED: <2015-09-29 Tue .+1w>

Re: [O] DEADLINE: position in entry

[Yasushi SHOJI]

Hi,

On Tue, Nov 22, 2016 at 3:08 AM, Sebastien Vauban <sva-n...@mygooglest.com>
wrote:
>
> Yasushi SHOJI <ya...@atmark-techno.com> writes:
> >  >8  cut  >8 
> > * DONE org
> >   DEADLINE: [2016-01-07 Thu 17:39]
> >
> >   SCHEDULED: <2015-09-29 Tue .+1w>
> >
> >  >8  cut  >8 
>
> A shoot in the dark: replace the [] by <>.
>
> [] for DEADLINE does not make much sense...

thanks for your comment.
chainging the inactive timestamp to active doesn't seem
to change the behavior.

even with an inactive time stamp, it's not a good excuse
to show a closed entry, isn't it?
-- 
yashi

Re: [O] DEADLINE: position in entry

[Yasushi SHOJI]

On Wed, 09 Nov 2016 18:37:00 +0900,
Alan Tyree wrote:
>
> Is this the way it should be? The first DEADLINE: shows up both as a
> warning and on the due date in the agenda, but the second one does
> not. It only works for me if the DEADLINE: is the first line after the
> heading. Version 9, emacs 24
>
> *** test 1
> DEADLINE: <2016-11-19 Sat>
>
> *** test 2
>
> DEADLINE: <2016-11-19 Sat>

at release_9.0.1-47-gb062593 with the following org file, org-agenda
shows the closed entry.  Is this also related?

Yes, org-lint complains about the 4th "scheduled" line saying:
"Misplaced planning info line", but isn't deadline planning info line?
is any of planning info line not allowed in the body?

 >8  cut  >8 
* DONE org
  DEADLINE: [2016-01-07 Thu 17:39]

  SCHEDULED: <2015-09-29 Tue .+1w>

 >8  cut  >8 
; /tmp/a.el
(add-to-list 'load-path "~/src/org-mode/lisp")
(setq org-agenda-files '("/tmp/a.org"))

 >8  cut  >8 

$ emacs -Q -l /tmp/a.el -f 'org-agenda'
-- 
 yashi

Re: [O] org: Fix tag width calculation for multi-column chars

[Yasushi SHOJI]

On Wed, 01 Jun 2016 14:57:04 +0900,
Georgiy Tugai wrote:
> 
> I'm not sure if this is the right place to ask, but would it be possible
> to implement, for lack of better terms, "virtual" tag positioning? In
> other words, the tags in the actual file are placed as usual
> (org-tags-column), but if a new variable (say, org-tags-column-display)
> is set, an overlay is placed onto each tag which results in the tags
> being shown at that location rather than where they actually are in the
> line?

Or, right align to the edge of your window would be nice. 

> I understand that this violates "what you see is what is in the file";
> however, this would allow (I believe) easier handling of windows where
> org-tags-column is wider than the window, as well as variable font sizes
> (f.e. some themes use large font sizes for headings, which interferes
> with tag positioning).
> 
> If this can be done and doesn't violate any of Org's design principles,
> I would appreciate some pointers on where to hook into Org to implement
> such a mechanism.

I'm not an expart but links in org document uses text property for
display?
-- 
yashi

Re: [O] [PATCH] org: Fix tag width calculation for multi-column chars

[Yasushi SHOJI]

Hi,

On Thu, 02 Jun 2016 02:34:31 +0900,
Nicolas Goaziou wrote:
> 
> > Would you remove the extra section marker (" Tags") thing when
> > merge to master?  It merges cleanly from maint to master but leaves
> > the marker.
> 
> I'll take care of the merging back to master.

Thank you.

> > please pull from:
> >
> >   https://github.com/yashi/org-mode tag-width-fix
> 
> I'd rather have the patch with the commit message as an attachment, if
> you don't mind.

Sure.  Attached.

Thanks,
-- 
 yashi

From b57dee1c44d8dd6979c5a6953ad12fdb487d5092 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI <ya...@atmark-techno.com>
Date: Tue, 31 May 2016 16:25:42 +0900
Subject: [PATCH 1/2] org: Fix tag width calculation for multi-column chars
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some characters have multiple column width.  Calculating string width
with points gives a wrong value than actual display width.  Use
`string-width' instead.

Here is an ECM for this problem.  `M-x org-update-statistics-cookies` or
`C-c #` on bar moves the tag on the headline.

* foo [0/0] :abc:
** child
* bar [0/0]  :日本語:
** child
12345678901234567890123456789012345678901234567890123456789012345678901234567890
 1 2 3 4 5 6 7 8
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index a9412ea..15f851d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14923,7 +14923,7 @@ If ONOFF is `on' or `off', don't toggle but set to this 
state."
 (if(and (looking-at (org-re ".*?\\([ 
\t]+\\)\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$"))
 (< pos (match-beginning 2)))
(progn
- (setq tags-l (- (match-end 2) (match-beginning 2)))
+ (setq tags-l (string-width (match-string 2)))
  (goto-char (match-beginning 1))
  (insert " ")
  (delete-region (point) (1+ (match-beginning 2)))
-- 
2.8.1

From 4cbd72931e7982878334c92abb08272f11ae0f32 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI <ya...@atmark-techno.com>
Date: Tue, 31 May 2016 16:25:42 +0900
Subject: [PATCH 2/2] org: Add test for tag width calculation

This is a simple unit test case for the previous fix.
---
 testing/lisp/test-org.el | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index db7e525..4873fc2 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -4132,6 +4132,28 @@ Paragraph"
(org-occur "A" nil (lambda () (equal (org-get-heading) "H2")))
 
 
+;;; Tags
+
+(ert-deftest test-org/tag-align ()
+  "Test `org-align-tags-here' with different display width."
+  (should
+   ;;  12345678901234567890
+   (equal "* Test :abc:"
+ (org-test-with-temp-text "* Test :abc:"
+   (let ((org-tags-column -20)
+ (indent-tabs-mode nil))
+(org-fix-tags-on-the-fly))
+   (buffer-string
+  (should
+   ;;  12345678901234567890
+   (equal "* Test  :日本語:"
+ (org-test-with-temp-text "* Test :日本語:"
+   (let ((org-tags-column -20)
+ (indent-tabs-mode nil))
+(org-fix-tags-on-the-fly))
+   (buffer-string)
+
+
 ;;; Timestamps API
 
 (ert-deftest test-org/time-stamp ()
-- 
2.8.1

Re: [O] [PATCH] org: Fix tag width calculation for multi-column chars

[Yasushi SHOJI]

Hi Samuel,

On Wed, 01 Jun 2016 06:06:02 +0900,
Samuel Wales wrote:
> 
> i wonder if this also fixes tags for variable pitch (proportional)
> fonts.  i have been having great success with variable pitch fonts and
> it would be great if this fixes tags for them too.

This fix is nothing to do with propotional fonts.  What kind of
problem do you have right now?  Any screen shot or an ECM?

If you are refering to the Ambiguous width defined in UAX#11, it might.
-- 
   yashi

Re: [O] [PATCH] org: Fix tag width calculation for multi-column chars

[Yasushi SHOJI]

Hi Nicolas,

On Wed, 01 Jun 2016 05:02:58 +0900,
Nicolas Goaziou wrote:
> Yasushi SHOJI <ya...@atmark-techno.com> writes:
> > Let me know if I miss something.
> 
> Could you send it again with an appropriate commit message and using git
> format-patch?

Oops.  Sorry about the format=flowed.  Not sure how I got that, but
might be gmail thing.  I'll use NNTP or git pull request next time.

> Also, there is already a "Tags" section in "test-org.el". Could you add
> your tests there instead of creating a new section?

Ah, the patch was intended for the branch maint.

Would you remove the extra section marker (" Tags") thing when
merge to master?  It merges cleanly from maint to master but leaves
the marker.

please pull from:

  https://github.com/yashi/org-mode tag-width-fix

ps. If you want me to change it for master, let me know.  I'll do it.
--
yashi

[O] [PATCH] org: Fix tag width calculation for multi-column chars

[Yasushi SHOJI]

Some characters have multiple column width.  Calculating string width
with points gives a wrong value than actual display width.  Use
`string-width' instead.

Here is an ECM for this problem.  `M-x org-update-statistics-cookies` or
`C-c #` on bar moves the tag on the headline.

* foo [0/0] :abc:
** child
* bar [0/0]  :日本語:
** child
12345678901234567890123456789012345678901234567890123456789012345678901234567890
 1 2 3 4 5 6 7 8

Simple test case is also included.
---

Hello,

While using Japanese as a tag, it seems to move the position of it
when `org-align-tags-here' is called.

If Japanese characters are allowed for tags, please merge it.

Let me know if I miss something.

Thanks,
yashi


 lisp/org.el  |  2 +-
 testing/lisp/test-org.el | 23 +++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index e4edcf4..d34163f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14922,7 +14922,7 @@ If ONOFF is `on' or `off', don't toggle but set to this 
state."
 (if(and (looking-at (org-re ".*?\\([ 
\t]+\\)\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$"))
 (< pos (match-beginning 2)))
(progn
- (setq tags-l (- (match-end 2) (match-beginning 2)))
+ (setq tags-l (string-width (match-string 2)))
  (goto-char (match-beginning 1))
  (insert " ")
  (delete-region (point) (1+ (match-beginning 2)))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 73245b4..7de0fa0 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -4406,6 +4406,29 @@ Paragraph"
   (funcall list-visible-lines 'canonical nil)
 
 
+
+;;; Tags
+
+(ert-deftest test-org/tag-align ()
+  "Test `org-align-tags-here' with different display width."
+  (should
+   ;;  12345678901234567890
+   (equal "* Test :abc:"
+ (org-test-with-temp-text "* Test :abc:"
+   (let ((org-tags-column -20)
+ (indent-tabs-mode nil))
+(org-fix-tags-on-the-fly))
+   (buffer-string
+  (should
+   ;;  12345678901234567890
+   (equal "* Test  :日本語:"
+ (org-test-with-temp-text "* Test :日本語:"
+   (let ((org-tags-column -20)
+ (indent-tabs-mode nil))
+(org-fix-tags-on-the-fly))
+   (buffer-string)
+
+
 (provide 'test-org)
 
 ;;; test-org.el ends here
-- 
2.8.1

[O] org-habit: "++" render wrong color

[Yasushi SHOJI]

Hi all,

Since 5d19c2c6891acd55dae36fccc07defe359a7283e, the habit consistency
graph renders intervals in wrong color if you use `++'.

http://ibin.co/2V80yaYqOT1O

The above graph in the pic is from 5d19c2c68~1, the below is the tip
of master.  Note that red region from the left most `*' to `!' at the
bad line.

Here is an ECM:

#+BEGIN_SRC lisp
  (add-to-list 'load-path "~/src/org-mode/lisp")
  (require 'org)
  (add-to-list 'org-modules 'org-habit)
  (setq org-agenda-files '("/tmp/a.org"))
  (org-agenda-list)
#+END_SRC

#+BEGIN_SRC org
* TODO bad
  SCHEDULED: <2016-01-27 Wed ++1w>
  :PROPERTIES:
  :STYLE:habit
  :END:
  - State "DONE"   from "TODO"   [2016-01-20 Wed 14:50]
  - State "DONE"   from "TODO"   [2016-01-13 Wed 14:50]

* TODO good
  SCHEDULED: <2016-01-27 Wed .+1w>
  :PROPERTIES:
  :STYLE:habit
  :END:
  - State "DONE"   from "TODO"   [2016-01-20 Wed 14:50]
  - State "DONE"   from "TODO"   [2016-01-13 Wed 14:50]
#+END_SRC
-- 
yashi

[O] http://orgmode.org/org.html: toc links broken

[Yasushi SHOJI]

Hi,

Not sure since when, but the TOC links of "Short Contents" at the top
of org.html are broken.  links pointing to the same section in the
menu at top right corner or in the toc under the "Org Mode Manual" are
fine.

I see "toc_" prefix in the bad links but not sure how to fix them.

Best,
-- 
   yashi

[O] ox: html: Wrong type argument: stringp, (latex-fragment

[Yasushi SHOJI]

Hi all,

With Org-mode version 8.3.2 (release_8.3.2-380-g64aee4),
org-html-export-to-html does not work with this ECM if
org-export-with-sub-superscripts is set to nil.

#+BEGIN_SRC org
  \_\A
#+END_SRC

Does anyone have seen this?
-- 
 yashi

Re: [O] inserting new heading

[Yasushi SHOJI]

At Thu, 15 May 2014 10:01:11 -0400,
Ralph Bacolod wrote:
 
 I recently found the joy of using Emacs and Org-mode. I'm using it to 
 organize a lot of stuff and just
 now I notice something that bothers me a lot. Whenever I am inserting a new 
 heading, via Ctrl-return or alt-return , the
 new heading skips a line. Is this the default behavior? If yes, is there a 
 variable that I can change somewhere?

(setq org-blank-before-new-entry '((heading . nil) (plain-list-item . auto)))

does the above line work for you?
-- 
  yashi

Re: [O] [PATCH] org-plot: Handle explicit date/time index

[Yasushi SHOJI]

Hi Bastien,

At Sun, 23 Mar 2014 19:41:45 +0100,
Bastien wrote:
 
 Yasushi SHOJI ya...@atmark-techno.com writes:
 
  * lisp/org-plot.el (org-plot-quote-tsv-field): Dump data as is when
`timeind' is set.
 
 This change produces a compiler warning:
 
 In org-plot-quote-tsv-field:
 org-plot.el:113:22:Warning: reference to free variable `params'

Thank you for catching this.

I guess I have to re-think the whole thing. The current code by-passes
the quoting function for _all_ fields, not just for the index when
`timeind' is present.  This surely breaks for others.

I don't have much time today.  So, please give me a day or two.
Meanwhile, Bastien, would you mind to revert the commit for me?

Thanks,
-- 
 yashi

Re: [O] [PATCH] org-plot: Handle explicit date/time index

[Yasushi SHOJI]

Hi Bastien,

At Thu, 13 Mar 2014 12:58:00 +0100,
Bastien wrote:
 
 I applied the patch.  Thanks for it.  I slightly modified
 the commit message, please review it:
 
 http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=e2b6c506

No problem at all.

Thanks,
-- 
  yashi

Re: [O] advice on ways to quicken refiling..perhaps a hotkey to refile to specific org file/header?

[Yasushi SHOJI]

Hi,

At Tue, 4 Mar 2014 17:43:41 +0200,
Xebar Saram wrote:
 
 i find the normal C-c w then manually choosing a file to allocate each
 'capture' pretty slow. i am looking for any advice on workflows you
 guys have to make this quicker.
 
 one thing i was thinking of was maybe assigning a hotkey to do a
 refile to a specific note/heading. so ill have 5-6 hotkeys to my most
 common files to speed things up, can this be done? if so can anyone
 show my an example of such a thing?

Nice idea.

A quick grance at `org-refile' in org.el, something like this will do:

(defun org-refile-to-myfile ()
  Refile to myfile.org
  (interactive)
  (org-refile nil nil '(my refiling pos myfile.org  0)))

The 3rd argument seems to be `(list message file re pos)', but not
sure how `re' and `pos' works.  Could someone enlignten me?
-- 
yashi

[O] [PATCH] org-plot: Handle explicit date/time index

[Yasushi SHOJI]

* lisp/org-plot.el (org-plot-quote-tsv-field): Dump data as is when
  `timeind' is set.

* lisp/org-plot.el (org-plot/gnuplot): By-pass type checking when
  either `textind' or `timeind' is set.

The current org-plot relies on `org-table-number-regexp' and
`org-ts-regexp3' to check the index type.  However, we already have
`timeind' to indicate that the index is the datatype of date/time.

By-pass the type checking in `org-plot/gnuplot' when either `textind'
or `timeind' is set.  The whole point of the check is to determine the
type. We do not need that when we already know.

Also dump the date/time data with `org-plot-quote-tsv-field' as is,
without double quotes, when `timeind' is set.  So that we can use
`timefmt' to read what we have.  Currently we do not have a good way
to specify `timefmt' with the double quotes.
---

Hi,

It seems to me that dates with slash (ie. 2014/03/11) does not work
with the current org-plot.el, even if you set `timeind' and
`timefmt'. That's because the current org-plot treat 2014/03/11 as
string instead of data/time.

Here is an ECM:

#+PLOT: ind:1
#+PLOT: timeind:t timefmt:%Y/%m/%d
#+PLOT: set:format x '%y-%m'
#+PLOT: set:xtics rotate by -45
| 2014/03/11 | 0 |
| 2014/03/12 | 1 |
| 2014/03/13 | 2 |

This patch fixes my itch but I'm not sure it doesn't break others.
Could you please test it? and tell me how it works.

BTW, do we have any test for org-plot?  Let me know if there is any.

Thanks,
-- 
yashi

 lisp/org-plot.el | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 556b9ef..b5000ea 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -109,7 +109,8 @@ will be added.  Returns the resulting property list.
 
 (defun org-plot-quote-tsv-field (s)
   Quote field S for export to gnuplot.
-  (if (string-match org-table-number-regexp s) s
+  (if (or (string-match org-table-number-regexp s)
+  (plist-get params :timeind)) s
 (if (string-match org-ts-regexp3 s)
(org-plot-quote-timestamp-field s)
   (concat \ (mapconcat 'identity (split-string s \) \\) \
@@ -312,7 +313,9 @@ line directly before or after the table.
 (when y-labels (plist-put params :ylabels y-labels)
   ;; check for timestamp ind column
   (let ((ind (- (plist-get params :ind) 1)))
-   (when (and (= ind 0) (equal '2d (plist-get params :plot-type)))
+(when (and (= ind 0) (equal '2d (plist-get params :plot-type))
+   (not (or (plist-get params :timeind)
+(plist-get params :textind
  (if (= (length
  (delq 0 (mapcar
   (lambda (el)
-- 
1.9.0

Re: [O] link interfering with brackets when abbreviated

[Yasushi SHOJI]

Hi Nicolas,

At Fri, 28 Feb 2014 00:43:19 +0100,
Nicolas Goaziou wrote:
 
 Bastien b...@altern.org writes:
 
  If it is not, I suggest to discuss the change before implementing it.
  Nobody ever complained about the previous behavior, and both Michael
  and me are suppporting it.
 
 I didn't remove that non-essential feature for my pleasure, but because
 it didn't fit in the new internal model. As I already said, implementing
 it back is a bit of work and will probably not be very clean. Why
 bother?

Let's separate those internal parser thing and interactive commands,
while we discus. I agree to Nicolas that parser and internal functions
should NOT be ambiguous nor confusing.

However, we humans are not machines nor slave of computers.  We tell
computers what we want, or even, we want to make computers think and
do what we are thinking. That's the reason why we, these days, have
*-dwim commands.  We don't want to make our users to adopt how
computers work.

 Anyway, I don't understand why there is so much fuss about this.

That's because a) the commands have been working, b) many other
commands _do_ work even if it's not right on the elements. ie. S-right
right after a timestamp, C-c C-c on checkbox list.  Are you planning
to remove these features, too?

 I think that the coolness of the feature eludes me for all I can see is
 a crude hack.

What if we create org-open-at-point-dwim and map to C-c C-o.  Nicolas,
do you object?

Anyway, thank you Nicolas for your work.  We all appreciate your great
work.

Thanks,
-- 
yashi

Re: [O] link interfering with brackets when abbreviated

[Yasushi SHOJI]

Hi Nicolas,

At Fri, 28 Feb 2014 00:43:19 +0100,
Nicolas Goaziou wrote:
 
 Bastien b...@altern.org writes:
 
  If it is not, I suggest to discuss the change before implementing it.
  Nobody ever complained about the previous behavior, and both Michael
  and me are suppporting it.
 
 I didn't remove that non-essential feature for my pleasure, but because
 it didn't fit in the new internal model. As I already said, implementing
 it back is a bit of work and will probably not be very clean. Why
 bother?

Let's separate those internal parser thing and interactive commands,
while we discus. I agree to Nicolas that parser and internal functions
should NOT be ambiguous nor confusing.

However, we humans are not machines nor slave of computers.  We tell
computers what we want, or even, we want to make computers think and
do what we are thinking. That's the reason why we, these days, have
*-dwim commands.  We don't want to make our users to adopt how
computers work.

 Anyway, I don't understand why there is so much fuss about this.

That's because a) the commands have been working, b) many other
commands _do_ work even if it's not right on the elements. ie. S-right
right after a timestamp, C-c C-c on checkbox list.  Are you planning
to remove these features, too?

 I think that the coolness of the feature eludes me for all I can see is
 a crude hack.

What if we create org-open-at-point-dwim and map to C-c C-o.  Nicolas,
do you object?

Anyway, thank you Nicolas for your work.  We all appreciate your great
work.

Thanks,
-- 
yashi

Re: [O] link interfering with brackets when abbreviated

[Yasushi SHOJI]

Hi Nicolas,

Thanks for your time.

At Sat, 01 Mar 2014 21:20:18 +0100,
Nicolas Goaziou wrote:
 
  Anyway, I don't understand why there is so much fuss about this.
 
  That's because a) the commands have been working
 
 This is not a sufficient reason. We are discussing a minor feature.
 Removing it doesn't remove any functionality to Org, as the thing just
 saves a few keystrokes, on a good day.

Ok.  If this is yet another bickshed, I'll drop from the discussion.

 While re-implementing the function, it appears that the feature just
 doesn't fit. So this is a good time to ponder about its real usefulness,
 and, if it is worth bending the new function to add it back. I think it
 isn't.
 
 As I already said, opening the next link in the same line is dubious. In
 the following example, with point between the links, the previous
 behaviour was to open link2:
 
   [[link1]]  [[link2]]
 
 Now consider the following case, where point is before the a:
 
   [[link1]] a very ... very long line of text [[link2]]
 
 The previous behaviour implied to also open link2. This is not
 really straightforward.

If the point is before the a, that means the point is right after
the link, it should open `link1' instead of `link2', IMNSHO.  This
isn't even the previous behavior, I admit, but if you move the pointer
to the end of the line (that's right after the link2), it _opened_
links2. This behavior works quite well with Emacs' cursor movement.

;; uga, `forward-word' doesn't work as I expected on
;; [[http://google.com][google]].  It stops at the first `o'.

  Worse, if `visual-line-mode' is on,
 [[link2]] can be many lines below. In the following case, with point
 still before the first a, opening [[link2]] is just odd:
 
   [[link1]] a very ... very long line
   which spans over many visual lines
   of text [[link2]].
 
 It is odd because in the same situation, without `visual-line-mode' but
 with `auto-fill-mode' on, C-c C-o will report No link found.

Both should report No link found.  `org-end-of-line' takes care of
`visual-line-mode', why not `org-open-at-link'?
-- 
  yashi

Re: [O] simple way to call `C-c a v' or a way to bind it to a key?

[Yasushi SHOJI]

At Mon, 17 Feb 2014 10:43:48 +0100,
Nicolas Richard wrote:
 
 Marc Ihm m...@ihm.name writes:
  (global-set-key (kbd f12) (lambda () (interactive) (execute-kbd-macro 
  (kbd C-c a v
 
 (global-set-key (kbd f12) (kbd C-c a v))

Ah, these are nice to know.  Thanks, guys.
-- 
yashi

Re: [O] parser: verbatim or code?

[Yasushi SHOJI]

Hi Nicolas,

At Sun, 16 Feb 2014 10:20:55 +0100,
Nicolas Goaziou wrote:
 
 If we do change them, it should only happen in org-element.el. I don't
 think that would break existing documents, as code and verbatim are
 really close to each other.
 
 I don't care either way. Though, I lean towards the first option, as
 I like = as verbatim (which may be the source of the initial
 confusion).

I'd suggest to keep documentation, and fix the code.

Because, our document serves our _user_ as the interface definition
and it's already been widely accepted.  Users expect to have marked up
code segment if they have =code= in their document.

;; It might be just me but I've been seen =code= in this mailing list
;; many times but never noticed ~code~, for example.
-- 
  yashi

Re: [O] simple way to call `C-c a v' or a way to bind it to a key?

[Yasushi SHOJI]

Hi Thorsten,

At Sat, 15 Feb 2014 18:34:07 +0100,
Thorsten Jolitz wrote:
 
 so instead of binding the dispatcher function to a global key you can
 bind one or more of the specific functions, e.g.
 
 ,
 | (global-set-key (kbd f12) 'org-agenda-list)
 `

I thought simply binding `org-agenda-list' to a key does not work in
the case with custome agenda setup.

But, it turns out that it's as simple as the following:

(defun yashi/org-agenda (optional arg)
  (interactive P)
  (org-agenda arg a))

(global-set-key (kbd f1) 'yashi/org-agenda)

Thanks,
-- 
 yashi

Re: [O] parser: verbatim or code?

[Yasushi SHOJI]

Hi,

At Sat, 15 Feb 2014 09:23:41 -0500,
Nick Dokos wrote:
 
 I think it's a code bug: ~verbatim~ is the precedent-setting latex
 convention.
 
 However fixing it might break existing documents (although in many
 instances code and verbatim are treated equivalently, so that might
 not be much of a problem).

A quick grep on export back-ends reveals that some back-ends uses them
differently. Namely

 - latex
 - man
 - org ;-)
 - texinfo

Should I just leave as-is?
-- 
   yashi

Re: [O] Best way to generate textile from orgmode ?

[Yasushi SHOJI]

Hi Marc,

# way too late to reply but...

At Thu, 11 Apr 2013 22:11:49 +0200,
Marc-Oliver Ihm wrote:
 
 i would like to convert orgmode to textile (which is used within confluence 
 wiki).

I was hoping that someone's gonna beat me to it. but hey, it's much
fun to write elisp than textile (it's redmine in my case ;-p).

https://github.com/yashi/org-textile

Only some basic formats are supported right now, but quite useful for
me, at least.  Hope it is as well for you.

It's also in melpa, thanks to @purcell.

Best,
-- 
yashi

[O] simple way to call `C-c a v' or a way to bind it to a key?

[Yasushi SHOJI]

Hello,

These days I hit `C-c a v' many many times a day, and now feel that
the three key combination is too much. I'd like to improve the
situation by binding the same functionality to a key, say, F12, if
possible.

Looking at the `org-agenda' dispatch code, there are quite a few lines
before calling `org-agenda-list'.  Simply binding `org-agenda-list' to
a key does not seem to work.

Is there a simple way to do it?  Or do I have to re-implement my own
function?

Thanks in advance,
-- 
  yashi

[O] parser: verbatim or code?

[Yasushi SHOJI]

Hello,

While writing a new exporter I've noticed that `=' is actually for
verbatim and `~' is for code emphasis despite the fact that the
current org manual says:

You can make words *bold*, /italic/, _underlined_, =code= and
~verbatim~

Is this documentation bug?

regards,
-- 
yashi

Re: [O] simple way to call `C-c a v' or a way to bind it to a key?

[Yasushi SHOJI]

Hi,

On Feb 15, 2014 11:38 PM, Thorsten Jolitz tjol...@gmail.com wrote:

,---
| (global-set-key (kbd f12) 'org-agenda)
`---

Thanks, but that's still two keys away. I want a single key to call the
function.

Regards,
-- 
yashi

[O] org-update-statistics-cookies does not update stats

[Yasushi SHOJI]

Bastien,

It seems to me that the commit 80fc5ad breaks
`org-update-statistics-cookies' on my setup.

Here is an ECM:

* foo [1/2]
** DONE bar
** TODO baz

Calling `org-update-statistics-cookies' on `foo' changes `[1/2]' to
`[0/2]'.  This doesn't affect the maint branch as I, just in case,
tested.  So, it's non-urgent issue.

Regards,
-- 
   yashi

Re: [O] [RFC] ox-ascii.el: fixing variable width character handling

[Yasushi SHOJI]

Hi,

At Fri, 03 Jan 2014 10:34:08 +0100,
Nicolas Goaziou wrote:
 
 Thank you. It looks mostly good, but I cannot apply it on top of master
 branch. Could you rebase and send an updated version?

Opps.  Rebased version attached.

 The usual format is
 
   (org-ascii--build-title, org-ascii--build-toc, ...): Likewise.
 
 IOW, you don't need a new line for each function.

Thanks.  I've now checked Emacs' Changelog.  It seems like each line
have open and close parentheses.  Am I right?

  -(let ((struct (org-element-property :structure parent-item))
  -  (beg-item (org-element-property :begin parent-item)))
  +(let* ((struct (org-element-property :structure parent-item))
  +   (beg-item (org-element-property :begin parent-item))
  +   (tag (org-list-get-tag beg-item struct))
  +   (bullet (org-list-get-bullet beg-item struct)))
 
 Since you don't use these variables below, you can skip both tag and
 bullet binding.

My bad.  Deleted.  New patch attached.

- 8 - 8 - 8 -
Subject: [PATCH] ox-ascii: Convert `length' to `string-width' where
 appropriate

* lisp/ox-ascii.el (org-ascii--current-text-width): Convert `length'
  to `string-width'.
  (org-ascii--build-title, org-ascii--build-toc)
  (org-ascii--list-listings, org-ascii--list-tables)
  (org-ascii-template--document-title)
  (org-ascii-inner-template, org-ascii-format-inlinetask-default)
  (org-ascii-format-inlinetask-default, org-ascii-item
  (org-ascii--table-cell-width, org-ascii-table-cell)
  (org-ascii--current-text-width): Likewise.

I've checked all occurrences of the function `length' in ox-ascii.el.
It turns out that the most of them are calculating the width of given
string. To support fullwidth characters, we better use `string-width'
instead of `length'.

Some characters in UCS are categorized as East Asian Ambiguous[1].
The return value of `string-width' with those characters depends on
how Emacs is setup.  We leave those ambiguous character handling to
Emacs.

Two usages of `length' in `ox-ascii.el' were left as-is, because those
were used for:

 - bullet depth calculation in `org-ascii-headline', and
 - cell position calculation in `org-ascii--table-cell-width'.

[1]: http://www.unicode.org/reports/tr11/#Ambiguous
---
 lisp/ox-ascii.el | 71 +++-
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index b278ab6..4b20afd 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -527,15 +527,16 @@ INFO is a plist used as a communication channel.
 ;; the list and current item bullet's length.  Also
 ;; remove checkbox length, and tag length (for
 ;; description lists) or bullet length.
-(let ((struct (org-element-property :structure parent-item))
-  (beg-item (org-element-property :begin parent-item)))
+(let* ((struct (org-element-property :structure parent-item))
+   (beg-item (org-element-property :begin parent-item)))
   (+ (- (org-list-get-ind beg-item struct)
 (org-list-get-ind
  (org-list-get-top-point struct) struct))
- (length (org-ascii--checkbox parent-item info))
- (length
+ (string-width (or (org-ascii--checkbox parent-item info) 
))
+ (string-width
   (or (org-list-get-tag beg-item struct)
-  (org-list-get-bullet beg-item struct)
+  (org-list-get-bullet beg-item struct)
+  
 
 (defun org-ascii--build-title
   (element info text-width optional underline notags toc)
@@ -591,7 +592,8 @@ possible.  It doesn't apply to `inlinetask' elements.
  (when tags
(format
(format  %%%ds
-   (max (- text-width  (1+ (length first-part))) (length tags)))
+   (max (- text-width (1+ (string-width first-part)))
+(string-width tags)))
tags))
  ;; Maybe underline text, if ELEMENT type is `headline' and an
  ;; underline character has been defined.
@@ -602,7 +604,9 @@ possible.  It doesn't apply to `inlinetask' elements.
  org-ascii-underline)
 (and under-char
  (concat \n
- (make-string (length first-part) under-char
+ (make-string (/ (string-width first-part)
+ (char-width under-char))
+  under-char
 
 (defun org-ascii--has-caption-p (element info)
   Non-nil when ELEMENT has a caption affiliated keyword.
@@ -649,7 +653,7 @@ which the table of contents generation has been initiated.
   (let ((title (org-ascii--translate Table of 

Re: [O] [PATCH] Table continuation strings

[Yasushi SHOJI]

Hi,

At Mon, 23 Dec 2013 10:09:44 +0100,
Nicolas Goaziou wrote:
 
 There's a limitation: if you use Latin1 characters (e.g. when you write
 in French), you cannot export to text/ascii anymore.
 
 So, if, for some reason, you really need to export to ascii only, but
 still need to write in french, you have to be careful not to use any of
 these Latin1 characters, in particular in translated strings. Similarly,
 Japanese :ascii entries could be written using romanji.
 
 I don't know to what extent it is useful, though.

Right.  It is doable, but for Japanese I don't think anyone wants to
do it, or at least not a ordinal usage, IMO.

  I'm checking exporters I use, including plain text and html, but it
  doesn't seems to go wrong. But I really needs some help for other
  back-ends. I'll post a patch for testing if anyone's interested in.
 
 Good idea.
 
 You can also set entries to :default and provide a different :latex
 value, if required.

Ok, I've checked what I can.  It seems working at least for me.  Let's
patch up the `org-export-dictionary' to see it breaks for others.

Here is a patch to convert all Japanese entries from :utf-8 to :default.
You can apply it with `git am --scissors'.

- 8 - cut here - 8 -
Subject: [PATCH 1/2] ox: Convert Japanese translation from utf-8 to default

* lisp/ox.el (org-export-dictionary): Convert all Japanese translation
  from utf-8 to default.

There shouldn't be much need for exporters and users to worry about
the coding system of the final output.  If one wants to export a
Japanese document, he should already have the document with Japanese
capable coding system. In that case, Emacs should be able to handle
the coding system conversion form the translation table to the
designated file coding system.

There are two cases which I can think don't work:

  - all words in the document are written in romaji, and one wants
romaji translations

  - the documents are writ en in a language which does not support
Japanese character set, ie English or French, and one wants to use
Japanese for non-content strings, ie TOC.

These cases are too rare that we can ignore for now.
---
 lisp/ox.el | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 2160826..592cc79 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5331,7 +5331,7 @@ them.
  (hu :default Szerzotilde;)
  (is :html Houml;fundur)
  (it :default Autore)
- (ja :html #33879;#32773; :utf-8 著者)
+ (ja :default 著者 :html #33879;#32773;)
  (nl :default Auteur)
  (no :default Forfatter)
  (nb :default Forfatter)
@@ -5347,7 +5347,7 @@ them.
  (es :default Continúa de la página anterior)
  (fr :default Suite de la page précédente)
  (it :default Continua da pagina precedente)
- (ja :utf-8 前ページからの続き)
+ (ja :default 前ページからの続き)
  (nl :default Vervolg van vorige pagina)
  (pt :default Continuação da página anterior)
  (ru :html 
(#1055;#1088;#1086;#1076;#1086;#1083;#1078;#1077;#1085;#1080;#1077;)
@@ -5357,7 +5357,7 @@ them.
  (es :default Continúa en la siguiente página)
  (fr :default Suite page suivante)
  (it :default Continua alla pagina successiva)
- (ja :utf-8 次ページに続く)
+ (ja :default 次ページに続く)
  (nl :default Vervolg op volgende pagina)
  (pt :default Continua na página seguinte)
  (ru :html 
(#1055;#1088;#1086;#1076;#1086;#1083;#1078;#1077;#1085;#1080;#1077; 
#1089;#1083;#1077;#1076;#1091;#1077;#1090;)
@@ -5374,7 +5374,7 @@ them.
  (hu :html Daacute;tum)
  (is :default Dagsetning)
  (it :default Data)
- (ja :html #26085;#20184; :utf-8 日付)
+ (ja :default 日付 :html #26085;#20184;)
  (nl :default Datum)
  (no :default Dato)
  (nb :default Dato)
@@ -5403,7 +5403,7 @@ them.
  (de :default Abbildung)
  (es :default Figura)
  (et :default Joonis)
- (ja :html #22259; :utf-8 図)
+ (ja :default 図 :html #22259;)
  (no :default Illustrasjon)
  (nb :default Illustrasjon)
  (nn :default Illustrasjon)
@@ -5416,7 +5416,7 @@ them.
  (es :default Figura %d:)
  (et :default Joonis %d:)
  (fr :default Figure %d : :html Figurenbsp;%dnbsp;:)
- (ja :html #22259;%d:  :utf-8 図%d: )
+ (ja :default 図%d:  :html #22259;%d: )
  (no :default Illustrasjon %d)
  (nb :default Illustrasjon %d)
  (nn :default Illustrasjon %d)
@@ -5436,7 +5436,7 @@ them.
  (hu :html Laacute;bjegyzet)
  (is :html Aftanmaacute;lsgreinar)
  (it :html Note a piegrave; di pagina)
- (ja :html #33050;#27880; :utf-8 脚注)
+ (ja :default 脚注 :html #33050;#27880;)
  (nl :default Voetnoten)
  (no :default Fotnoter)
  (nb :default Fotnoter)
@@ -5497,7 +5497,7 @@ them.
  (es :default Tabla)
  (et :default Tabel)
  (fr :default Tableau)
- (ja :html #34920; :utf-8 表)
+ (ja :default 表 :html #34920;)
  (ru :html #1058;#1072;#1073;#1083;#1080;#1094;#1072; :utf-8 
Таблица)
  

Re: [O] [PATCH] Table continuation strings

[Yasushi SHOJI]

Hi,

At Thu, 02 Jan 2014 17:15:17 +0900,
Yasushi SHOJI wrote:
 
 At Mon, 23 Dec 2013 10:09:44 +0100,
 Nicolas Goaziou wrote:
  
  There's a limitation: if you use Latin1 characters (e.g. when you write
  in French), you cannot export to text/ascii anymore.
  
  So, if, for some reason, you really need to export to ascii only, but
  still need to write in french, you have to be careful not to use any of
  these Latin1 characters, in particular in translated strings. Similarly,
  Japanese :ascii entries could be written using romanji.
  
  I don't know to what extent it is useful, though.
 
 Right.  It is doable, but for Japanese I don't think anyone wants to
 do it, or at least not a ordinal usage, IMO.
 
   I'm checking exporters I use, including plain text and html, but it
   doesn't seems to go wrong. But I really needs some help for other
   back-ends. I'll post a patch for testing if anyone's interested in.
  
  Good idea.
  
  You can also set entries to :default and provide a different :latex
  value, if required.
 
 Ok, I've checked what I can.  It seems working at least for me.  Let's
 patch up the `org-export-dictionary' to see it breaks for others.
 
 Here is a patch to convert all Japanese entries from :utf-8 to :default.
 You can apply it with `git am --scissors'.

And here is a patch for the rest of Japanese translation strings.

- 8 - cut here - 8 -
Subject: [PATCH 2/2] ox: Add new Japanese translation strings

* lisp/ox.el (org-export-dictionary): Add new Japanese translation
  strings.

A few strings in `org-export-dictionary' didn't have Japanese
translations.  So, I just added.
---
 lisp/ox.el | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index 592cc79..ed7afe5 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5391,6 +5391,7 @@ them.
  (es :html Ecuacioacute;n :default Ecuación)
  (et :html V#245;rrand :utf-8 Võrrand)
  (fr :ascii Equation :default Équation)
+ (ja :default 方程式)
  (no :default Ligning)
  (nb :default Ligning)
  (nn :default Likning)
@@ -5454,6 +5455,7 @@ them.
  (es :default Indice de Listados de programas)
  (et :default Loendite nimekiri)
  (fr :default Liste des programmes)
+ (ja :default ソースコード目次)
  (no :default Dataprogrammer)
  (nb :default Dataprogrammer)
  (ru :html #1057;#1087;#1080;#1089;#1086;#1082; 
#1088;#1072;#1089;#1087;#1077;#1095;#1072;#1090;#1086;#1082;
@@ -5465,6 +5467,7 @@ them.
  (es :default Indice de tablas)
  (et :default Tabelite nimekiri)
  (fr :default Liste des tableaux)
+ (ja :default 表目次)
  (no :default Tabeller)
  (nb :default Tabeller)
  (nn :default Tabeller)
@@ -5478,6 +5481,7 @@ them.
  (es :default Listado de programa %d)
  (et :default Loend %d)
  (fr :default Programme %d : :html Programmenbsp;%dnbsp;:)
+ (ja :default ソースコード%d:)
  (no :default Dataprogram %d)
  (nb :default Dataprogram %d)
  (ru :html 
#1056;#1072;#1089;#1087;#1077;#1095;#1072;#1090;#1082;#1072; %d.:
@@ -5489,6 +5493,7 @@ them.
  (es :default vea seccion %s)
  (et :html Vaata peat#252;kki %s :utf-8 Vaata peatükki %s)
  (fr :default cf. section %s)
+ (ja :default セクション %s を参照)
  (ru :html #1057;#1084;. #1088;#1072;#1079;#1076;#1077;#1083; 
%s
   :utf-8 См. раздел %s)
  (zh-CN :html #21442;#35265;#31532;%s#33410; :utf-8 参见第%s节))
@@ -5545,6 +5550,7 @@ them.
  (es :default referencia desconocida)
  (et :default Tundmatu viide)
  (fr :ascii Destination inconnue :default Référence inconnue)
+ (ja :default 不明な参照先)
  (ru :html 
#1053;#1077;#1080;#1079;#1074;#1077;#1089;#1090;#1085;#1072;#1103; 
#1089;#1089;#1099;#1083;#1082;#1072;
   :utf-8 Неизвестная ссылка)
  (zh-CN :html #26410;#30693;#24341;#29992; :utf-8 未知引用)))
-- 
1.8.5.2


-- 
   yashi

Re: [O] [RFC] ox-ascii.el: fixing variable width character handling

[Yasushi SHOJI]

Hi Nicolas,

Took me a while to get back to this.

At Sun, 10 Nov 2013 14:09:48 +0100,
Nicolas Goaziou wrote:

  While I came up with the following experimental patch, I have a few
  questions:
 
   - What is the lisp idiom to handle type error?  In the following
 patch, I've created a new wrapper function
 `org-ascii--string-width', it's a thin wrapper with if-then-else.
 I thought placing if-then-else clause in the original place clutter
 the code.

 You only use `org-ascii--string-width' in two places. You can write

   (string-width (or contents ))

 instead, it will be less intrusive.

Thanks! I've used this idiom in the attached patch.

 BTW, what about `org-ascii--current-text-width'? This function also uses
 `length' instead of `string-width'.

I've checked all occurences of `length' in ox-ascii.el.  It turns out
that only two were used *not* for width calculation.

   - If wrapped string-width is good idea, would it be also a good idea
 to merge it with `org-string-width' in org.el?  Because it is not
 ox-ascii specific.  The current `org-string-width' does not handle
 nil, neither.

 That would be a good idea, but in a distinct patch.

Will do when I have time. 

   - The width of the underline for headlines should be checked with
 string-width.
 
 As defined in Unicode Standard Annex #41[1], character width is
 environment dependent.  So, the calculation of character width at
 export time might not be sufficient enough.  We can check to see
 the exported document contains cjk chars more than some thresholds
 or not, I haven't gone that far.

 I don't think there's much to do about it. Hopefully one can always
 re-export the Org file in its own environment.

   - Does anyone using ox-ascii.el depends on the clipped marker `='
 for fixed width columns?  I thought `...' would be much readable.

 I have no opinion about it. Though, if we switch to ..., we also need
 to provide the utf-8 equivalent when using this charset.

Will do next time.

   - BTW, while looking at table handling, I noticed fixed column width
 doesn't work with the code at the current git HEAD.  That's because
 width calculation is mixed with `length' and `string-width', and
 pass out-of-range arguments to `add-text-properties'.

 I guess your patch also fixed that.

Ok here is new one.  I've been using for a while.  Hope it works for
others.

- 8 - 8 - 8 - 8 -

Subject: [PATCH] ox-ascii: Convert `length' to `string-width' where
 appropriate

* lisp/ox-ascii.el (org-ascii--current-text-width): Convert `length'
  to `string-width'.
  (org-ascii--build-title): Likewise.
  (org-ascii--build-toc): Likewise.
  (org-ascii--list-listings): Likewise.
  (org-ascii--list-tables): Likewise.
  (org-ascii-template--document-title): Likewise.
  (org-ascii-inner-template): Likewise.
  (org-ascii-format-inlinetask-default): Likewise.
  (org-ascii-format-inlinetask-default):Likewise.
  (org-ascii-item): Likewise.
  (org-ascii--table-cell-width): Likewise.
  (org-ascii-table-cell): Likewise.
  (org-ascii--current-text-width): Likewise.

I've checked all occurrences of the function `length' in ox-ascii.el.
It turns out that the most of them are calculating the width of given
string. To support fullwidth characters, we better use `string-width'
instead of `length'.

Some characters in UCS are categorized as East Asian Ambiguous[1].
The return value of `string-width' with those characters depends on
how Emacs is setup.  We leave those ambiguous character handling to
Emacs.

Two usages of `length' in `ox-ascii.el' were left as-is, because those
were used for:

 - bullet position calculation in `org-ascii-headline', and
 - cell position calculation in `org-ascii--table-cell-width'.

[1]: http://www.unicode.org/reports/tr11/#Ambiguous
---
 lisp/ox-ascii.el | 73 
 1 file changed, 42 insertions(+), 31 deletions(-)

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index b278ab6..5291a2d 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -527,15 +527,18 @@ INFO is a plist used as a communication channel.
 ;; the list and current item bullet's length.  Also
 ;; remove checkbox length, and tag length (for
 ;; description lists) or bullet length.
-(let ((struct (org-element-property :structure parent-item))
-  (beg-item (org-element-property :begin parent-item)))
+(let* ((struct (org-element-property :structure parent-item))
+   (beg-item (org-element-property :begin parent-item))
+   (tag (org-list-get-tag beg-item struct))
+   (bullet (org-list-get-bullet beg-item struct)))
   (+ (- (org-list-get-ind beg-item struct)
 (org-list-get-ind
  (org-list-get-top-point struct) struct))
-

Re: [O] [PATCH] Table continuation strings

[Yasushi SHOJI]

Hi Nicolas,

At Sun, 22 Dec 2013 09:20:57 +0100,
Nicolas Goaziou wrote:
 
 Yasushi SHOJI ya...@atmark-techno.com writes:
 
  Ah, OK.  Those coding keys are for the back-ends to select proper
  strings, not for the string encoding.
 
 This is also related to string encoding. You will get garbage if you
 insert a string containing characters outside the encoding you use to
 save the file, won't you?

Right.

However, as you described below, the output file's encoding is not
determined by the language option, but by the current buffer coding
system, org-export-coding-system, or back-end specific variable, ie
org-html-coding-system.

That means that whenever your-choice-of-coding-system can handle the
characters for the translation string, meaning that the coding
system has code points for all of the characters of the translation
string and Emacs can convert between them, it is free to use any
character for the output, right?

If one wants to use French, she sets the current buffer coding system
to any coding system which can handle French and set the language
option as fr.  In that case, her/his org buffer should already have
French characters in it, there is no need for translation string to be
strictly ASCII only when you export with plain / ascii, no?

I just don't see any use case. I must have missed something here.
Please enlighten me.

BTW, Here is a part of quick test I've done.

   source  lang  exporter o-e-c-s  o-h-c-s  target buffer   
   target file   
  
---
   euc-jp  japlain/ascii  nil  -euc-jp  
   euc-jp
   euc-jp  japlain/utf-8  nil  -euc-jp  
   euc-jp
   euc-jp  japlain/ascii  utf-8-euc-jp  
   utf-8 
   euc-jp  japlain/utf-8  utf-8-euc-jp  
   utf-8 
   euc-jp  jahtml nil  utf-8euc-jp w/ charset=utf-8 
   utf-8 
   euc-jp  jahtml nil  euc-jp   euc-jp w/ charset=euc-jp
   euc-jp w/ charset=euc-jp  
  
---
   euc-jp  frplain/ascii  nil  -euc-jp w/ fr trans  
   euc-jp w/ fr translation  
   euc-jp  frplain/utf-8  nil  -euc-jp w/ fr trans  utf-8 
decoration  euc-jp w/ fr trans  utf-8 decoration 

All major encoding for Japanese, euc-jp, iso2022, shift-jis, and utf-8
can handle the current translation string without problem. So I'm
assuming that encoding for other language must have some problem.

  Then, is there any restriction with HTML back-ends? Why does it need
  numeric character reference instead of just plain characters, if the
  coding system is not a concern?
 
 See above. You may want to save your html file in a different encoding
 than UTF-8. IIUC, numeric character reference are more generic.

I agree that numeric reference is more generic.  As I've just checked,
HTML even allows us to put characters outside of the current content
charset with numeric reference!

# italian text exported as html with ja language option.  even if
# html has iso-8859-1 as charset, web browser shows japanese chars.

  If my understanding is ok, all entries of Japanese translation should
  have :default instead of :utf-8.
 
 :default instead of :utf-8 means Org will use these translations also
 for LaTeX, HTML and ASCII export. If you think that is correct, then we
 can switch to :default, indeed.

Since I don't use LaTeX, I have no idea about it. I hope some LaTeX
user help me here.

I'm checking exporters I use, including plain text and html, but it
doesn't seems to go wrong. But I really needs some help for other
back-ends. I'll post a patch for testing if anyone's interested in.

Thanks,
-- 
   yashi

Re: [O] [PATCH] Table continuation strings

[Yasushi SHOJI]

HI,

At Sat, 21 Dec 2013 10:05:35 +0100,
Nicolas Goaziou wrote:
 
 Yasushi SHOJI ya...@atmark-techno.com writes:
 
  The thing I don't understand is the reason all Japanese entries have
  `:utf-8'. Would you kindly enlighten me the relationship among the
  followings:
 
   - transtion coding key (ie :utf-8, :default, :html)
   - your current buffer coding system
   - `buffer-file-coding-system' and friends
 
 Coding keys are related to export back-ends. Therefore :latex entry will
 be used for `latex' export, :html for `html' export, `:utf-8' for both
 text (utf-8) and odt export, and so on.
 
 As its name suggests, :default key is used as a fallback value when no
 appropriate property is found. It makes up for a handy shortcut when
 some strings are identical.

Ah, OK.  Those coding keys are for the back-ends to select proper
strings, not for the string encoding.

Then, is there any restriction with HTML back-ends? Why does it need
numeric character reference instead of just plain characters, if the
coding system is not a concern?

 Coding system is a different thing. When `org-export-coding-system' is
 non-nil, it will be used as the coding system for output (note that some
 export back-ends override this behaviour). Otherwise, output will have
 the same encoding as the source buffer.

Correct me if I'm wrong.  My understainding is as follows: All
translation strings is in `emacs-internal' coding system, since it is
defined in .el.  A org file ready to be exported has a coding system
specific to the buffer, ie. utf-8, iso-latin-1, euc-jp, etc.

Org export back-ends get a strings for the back-ends from the
translation table when appropriate.  At that time Emacs converts the
strings encoding system to match the buffer encoding system (or does
Emacs convert all encoding when it writes to file?).  Back-ends uses
`org-export-coding-system' if set, otherwise use the current buffer
coding system.


If my understanding is ok, all entries of Japanese translation should
have :default instead of :utf-8.

Thanks,
-- 
yashi

Re: [O] [PATCH] Table continuation strings

[Yasushi SHOJI]

Hi,

At Wed, 30 Oct 2013 11:15:36 +0100,
Nicolas Goaziou wrote:
 
 t...@tsdye.com (Thomas S. Dye) writes:
 
  Patch includes table continuation strings for several languages.
  Translations all from the internet.  Caveat emptor.
 
 Applied. Thank you.
 
  + (ja :utf-8 前ページから続く)
 
 [...]
 
  + (ja :utf-8 次ページに続く)
 
 These will not be very helpful, though, as `latex' back-end (the only
 one to use this string so far) relies on :latex or :default properties,
 never on :utf-8.

I'm not a latex user but a Japanese speaker who'd like to use those
translation tables with other backends.

The thing I don't understand is the reason all Japanese entries have
`:utf-8'. Would you kindly enlighten me the relationship among the
followings:

 - transtion coding key (ie :utf-8, :default, :html)
 - your current buffer coding system
 - `buffer-file-coding-system' and friends

BTW, 前ページから続く should be 前ページからの続き

Thanks,
-- 
   yashi

Re: [O] Insert a heading in every sibling

[Yasushi SHOJI]

Hi,

At Mon, 28 Oct 2013 06:13:21 +0500,
Scot Becker wrote:
 
 I'm using org-mode to keep track of student grades.  How can I easily add a
 bunch of identical headings at a certain level in my tree?   Specifically,I
 have a L2 heading for each student, and I want to put a node (heading, with
 some properties) under each L2 student heading for that class.

It is not a org solution but I'd recommend using multiple cursor by
Magnar Sveen of Emacs rocks.

 - http://emacsrocks.com/e13.html
 - https://github.com/magnars/multiple-cursors.el

 * Class One
 ** Sarah Adams
 *** Essay One
 Here is my comment to the student on their essay.  The grade/mark itself
 will be stored as a property or priority.
[...]

In the case of above, do the following after properly installed mc:

 1. mark `Essay One'
 2. call `mc/mark-all-like-this'
 3. C-Enter
 4. Type 'Essay Two'

Viola! Now you have new `Essay Two' entries even if you already have
one. ;-p

My two cents,
-- 
  yashi

Re: [O] [bug] [babel] repeated exports w/ inline src blocks yield different results

[Yasushi SHOJI]

At Sun, 24 Nov 2013 04:18:38 + (UTC),
Charles Berry wrote:
[...]
 and you see the extra '#+END_SRC' line.
 
 And if you keep repeating those keystrokes, the second result again appears.
 
 However, sometimes a minor change and then an erasure (perhaps 'a a C-x u')
 followed by the export keystrokes yields the correct result.

It seems like a cache issue.  `org-element-cache-reset' before exporting
corrects the result on my system.

still learning how the cache works...
-- 
yashi

[O] [RFC] ox-ascii.el: fixing variable width character handling

[Yasushi SHOJI]

Hi,

I've been trying to fix ASCII export back-end for variable width
chars. It is basically replacing `length' with `string-width', but the
behavior of those two functions differ when you give nil as an
argument; `length' returns 0, `string-width' yields a type error:
eval: Wrong type argument: stringp, nil

While I came up with the following experimental patch, I have a few
questions:

 - What is the lisp idiom to handle type error?  In the following
   patch, I've created a new wrapper function
   `org-ascii--string-width', it's a thin wrapper with if-then-else.
   I thought placing if-then-else clause in the original place clutter
   the code.

 - If wrapped string-width is good idea, would it be also a good idea
   to merge it with `org-string-width' in org.el?  Because it is not
   ox-ascii specific.  The current `org-string-width' does not handle
   nil, neither.

 - The width of the underline for headlines should be checked with
   string-width.

   As defined in Unicode Standard Annex #41[1], character width is
   environment dependent.  So, the calculation of character width at
   export time might not be sufficient enough.  We can check to see
   the exported document contains cjk chars more than some thresholds
   or not, I haven't gone that far.

 - Does anyone using ox-ascii.el depends on the clipped marker `='
   for fixed width columns?  I thought `...' would be much readable.

 - BTW, while looking at table handling, I noticed fixed column width
   doesn't work with the code at the current git HEAD.  That's because
   width calculation is mixed with `length' and `string-width', and
   pass out-of-range arguments to `add-text-properties'.


[1]: http://www.unicode.org/reports/tr41/

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index 8e75007..35d58fc 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -630,7 +630,8 @@ possible.  It doesn't apply to `inlinetask' elements.
  org-ascii-underline)
 (and under-char
  (concat \n
- (make-string (length first-part) under-char
+ (make-string (/ (string-width first-part) (char-width 
under-char))
+  under-char
 
 (defun org-ascii--has-caption-p (element info)
   Non-nil when ELEMENT has a caption affiliated keyword.
@@ -1704,7 +1705,7 @@ are ignored.
   (org-element-map table 'table-row
 (lambda (row)
   (setq max-width
-(max (length
+(max (string-width
   (org-export-data
(org-element-contents
 (elt (org-element-contents row) col))
@@ -1714,6 +1715,11 @@ are ignored.
   max-width))
 cache
 
+(defun org-ascii--string-width (str)
+  (if str
+  (string-width str)
+0))
+
 (defun org-ascii-table-cell (table-cell contents info)
   Transcode a TABLE-CELL object from Org to ASCII.
 CONTENTS is the cell contents.  INFO is a plist used as
@@ -1724,16 +1730,18 @@ a communication channel.
   ;; each cell in the column.
   (let ((width (org-ascii--table-cell-width table-cell info)))
 ;; When contents are too large, truncate them.
-(unless (or org-ascii-table-widen-columns (= (length contents) width))
-  (setq contents (concat (substring contents 0 (- width 2)) =)))
+(unless (or org-ascii-table-widen-columns
+   (= (org-ascii--string-width contents) width))
+  (setq contents (truncate-string-to-width contents width nil ?. t)))
 ;; Align contents correctly within the cell.
 (let* ((indent-tabs-mode nil)
   (data
(when contents
  (org-ascii--justify-string
   contents width
-  (org-export-table-cell-alignment table-cell info)
-  (setq contents (concat data (make-string (- width (length data)) ? 
+  (org-export-table-cell-alignment table-cell info
+  (trailing-space (make-string (- width (org-ascii--string-width 
data)) ? )))
+  (setq contents (concat data trailing-space)))
 ;; Return cell.
 (concat (format  %s  contents)
(when (memq 'right (org-export-table-cell-borders table-cell info))

[O] [PATCH] lisp/org.el (org-set-tags): Calculate width of tags with string-width

[Yasushi SHOJI]

* lisp/org.el (org-set-tags): Width of strings presenting on a buffer
should be calculated with `string-width' instead of `length'.

This fixes unaligned tags for the languages with multi-width
characters.
---
Hi,

I just noticed that tags are not aligned when I use Japanese chars for
tags.  This patch should fix it.

Other two usages of `length' in the function are fine since they seem
to be used to find the length of lists.

oh, I also found one trailing white space in the fine.  Please drop
that hunk if you don't want to mix it.

Best,

 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 5ff9969..a6df29d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14556,7 +14556,7 @@ With prefix ARG, realign all tags in headings in the 
current buffer.
   0)
  p0 (if (equal (char-before) ?*) (1+ (point)) (point))
  tc (+ org-tags-column (if ( org-tags-column 0) (- di) di))
- c1 (max (1+ c0) (if ( tc 0) tc (- (- tc) (length tags
+ c1 (max (1+ c0) (if ( tc 0) tc (- (- tc) (string-width 
tags
  rpl (concat (make-string (max 0 (- c1 c0)) ?\ ) tags)))
  (replace-match rpl t t)
  (and (not (featurep 'xemacs)) c0 indent-tabs-mode (tabify p0 (point)))
@@ -20385,7 +20385,7 @@ If `org-special-ctrl-o' is nil, just call `open-line' 
everywhere.
 (open-line n))
((org-at-table-p)
 (org-table-insert-row))
-   (t
+   (t
 (open-line n
 
 (defun org-return (optional indent)
-- 
1.8.4.rc3

[O] Bug: org-meta-return in narrowed buffer makes the last line invisible

[Yasushi SHOJI]

Hi,

In my current environment, org-meta-return seems to make the last line
of a buffer invisible if the buffer is narrowed.  At first I thought
the lines are gone but that was false.  All text are there but you
can't see it.

First, here is my environment:

 - Org-mode version 8.0.3 (release_8.0.3-150-g61d8eb @ 
/home/yashi/src/org-mode/lisp/)
 - GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of
   2013-04-14 on trouble, modified by Debian
 - uname -a: Linux leno 3.8-2-amd64 #1 SMP Debian 3.8.13-1 x86_64 GNU/Linux
 - Debian Sid


Second, here is my step to reproduce:

 1. create a file with the following lines:
 #+BEGIN_SRC org
   ,* head
   ,** the last line in the narrow
   ,* the last line
 #+END_SRC
 2. emacs -Q
 3. open the above file
 4. narrow the buffer at 'head' with org-narrow-to-subtree
to make the contents as below:
 #+BEGIN_SRC org
   ,* head
   ,** the last line in the narrow
 #+END_SRC
 5. org-meta-enter at the end of the first line.
this makes the visible contents to be
 #+BEGIN_SRC org
   ,* head
   ,** the last line in the nar
 #+END_SRC

 notice that narrow became nar


Is this reproducible?  Does anyone see this bug?

Thanks,
-- 
   yashi

Re: [O] New Exporter: plain list depth

[Yasushi SHOJI]

Hi,

At Mon, 22 Apr 2013 00:10:25 +0200,
Nicolas Goaziou wrote:
 
 Yasushi SHOJI ya...@atmark-techno.com writes:
 
  To generate -- at the list 2.1, I'd like to find out the list 2.1 is
  at depth 2, so that I can use (make-string 2 ?-) for my bullet.
 
 Something like the following should work, assuming ITEM is the item
 element you have to transcode:
 
 #+begin_src emacs-lisp
 (let ((parent item) (depth 0))
   (while (and (setq parent (org-export-get-parent parent))
   (case (org-element-type parent)
 (item t)
 (plain-list (incf depth)
   depth)
 #+end_src

Thanks!  will try based on your advice.

  Does org-list-to-generic work in this situation?
 
 As a good rule of thumb, it's best to rely on tools provided in ox.el.

ok.

regards,
-- 
yashi

[O] New Exporter: plain list depth

[Yasushi SHOJI]

Hi,

What is the best way to know the depth of list entries when I writing
an exporter back-end?

let's say I have:

#+BEGIN_SRC org
  * headline 1
- list 1
- list 2
  - list 2.1
#+END_SRC

I'd like to convert it to:

#+BEGIN_EXAMPLE
  * headline 1
  - list 1
  - list 2
  -- list 2.1
#+END_EXAMPLE


To generate -- at the list 2.1, I'd like to find out the list 2.1 is
at depth 2, so that I can use (make-string 2 ?-) for my bullet.

What I came up with instead was to

 1) mark each item in item handler with -
 2) add a - in each plain-list handler
 3) remove one - from all list entries at final-function

it works, but it doesn't look good to me (tm).

I've checked a few exporters, including ox-html and ox-md but couldn't
find a function like org-export-get-relative-level for headline. Does
org-list-to-generic work in this situation?

Thanks,
-- 
yashi

[O] testing/README: need to enable sh and org for the current test

[Yasushi SHOJI]

Hello,

With the current HEAD(release_7.9.3d-894-gfe805ed), it seems we need
to load sh and org for babel language to run the test sucessfully.

#+BEGIN_SRC elisp
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((emacs-lisp . t)
 (sh . t)
 (org . t)))
  (setq org-confirm-babel-evaluate nil)
#+END_SRC

Am I missing something? Does it work as documented in testing/README
for everyone?

if not, should we patch the README like this? (just an idea, not completed)

diff --git a/testing/README b/testing/README
index 8ce7a19..9601ea7 100644
--- a/testing/README
+++ b/testing/README
@@ -15,12 +15,16 @@ The simplest way to run the Org-mode test suite is from the 
command
 line with the following invocation.  Note that the paths below are
 relative to the base of the Org-mode directory.
 
+Also note that many of the current tests uses babel evaluation...
+
 #+BEGIN_SRC sh :dir (expand-file-name ..)
   # For Emacs earlier than 24, add -L /path/to/ert
   emacs -Q --batch \
 -L lisp/ -L testing/ -L testing/lisp -l lisp/org.el \
 -l lisp/org-id.el -l testing/org-test.el \
---eval (progn (org-reload) (setq org-confirm-babel-evaluate nil)) \
+--eval (progn (org-reload) (setq org-confirm-babel-evaluate nil) \
+(org-babel-do-load-languages 'org-babel-load-languages \
+'((emacs-lisp . t) (sh . t) (org . t \
 -f org-test-run-batch-tests
 #+END_SRC
 
@@ -43,7 +47,12 @@ load and run the test suite with the following commands.
  (require 'org-test)
#+END_SRC
 
-2) Then run the test suite,
+2) Disable babel evaluation confirmation
+   #+BEGIN_SRC emacs-lisp
+ (setq org-confirm-babel-evaluate)
+   #+END_SRC
+
+3) Then run the test suite,
#+BEGIN_SRC emacs-lisp
  (org-test-run-all-tests)
#+END_SRC
-- 
   yashi