Current Org-mode does not work with Emacs 27
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/)]
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?
Hi, On Wed, Feb 7, 2018 at 8:35 AM, Kaushal Modiwrote: > 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
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
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
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
Hi, On Fri, Feb 2, 2018 at 4:41 PM, Alan Schmittwrote: >> 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
Hi, On Fri, Feb 2, 2018 at 10:24 AM, numbch...@gmail.comwrote: > 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
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
Hi, On Thu, Feb 1, 2018 at 9:29 PM, Alan Schmittwrote: > 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
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
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
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?
Hi, On Thu, Feb 1, 2018 at 8:47 AM, John Kitchinwrote: > 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
Hi, On Fri, Jan 26, 2018 at 2:37 AM, Alan Schmittwrote: > 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
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
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
Hi Nicolas, On Wed, Jan 24, 2018 at 8:28 PM, Nicolas Goaziouwrote: > 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
Hi, On Mon, Jan 22, 2018 at 10:54 PM, Rasmuswrote: > 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?
Hi, On Sat, Dec 23, 2017 at 11:12 PM, Kaushal Modiwrote: > 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?
Hi Nicolas, On Sun, Dec 17, 2017 at 7:34 PM, Nicolas Goaziouwrote: > 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?
Hi, On Wed, Dec 20, 2017 at 11:57 PM, Shiyao MAwrote: > 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?
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?
Hi, On Tue, Dec 19, 2017 at 9:57 AM, Shiyao MAwrote: > 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?
Hi, On Wed, Sep 27, 2017 at 3:27 AM, ConcreteVitaminwrote: > 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
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
Hi Bob, On Mon, Apr 3, 2017 at 1:34 PM, Bob Newellwrote: > > 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/)]
Hi Christof, On Sun, Mar 26, 2017 at 7:37 AM, Christof Musikwrote: > > 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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
* 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
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
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
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?
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?
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?
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?
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 ?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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