[O] MobileOrg: index.org links files to the wrong folder
Hi,
I really enjoy the MobileOrg project. However, since some time, I cannot
access my org files anymore from my iPhone (I see the file names, but
nodes are empty). After some search, I found that the links made in the
index.org point relatively to the org-directory while they are supposed
(if I'm understanding correctly) to point to the org files in the same
directory as the index.org (that is in org-mobile-directory). My emacs
configuration is the following:
(setq org-directory "~/Dropbox/env/org-mode-files")
(setq org-mobile-inbox-for-pull "~/Dropbox/env/org-mode-files/flagged.org")
(setq org-mobile-directory "~/Dropbox/Apps/MobileOrg")
(setq org-mobile-files '("~/org-mode-files/test.org"))
The generated index.org file in MobileOrg/ looks like:
#+READONLY
#+TODO: TODO
#+TODO: NEXT WAITING SOMEDAY |
#+TAGS: @HOME WORK EMAIL CALL READ ERRAND AGENDAS
#+ALLPRIORITIES: A B C
* [[file:agendas.org][Agenda Views]]
* [[file:~/org-mode-files/test.org][test.org]]
The test.org file cannot be read from my iPhone since only the
org-mobile-directory is accessible to it.
I cannot see from the code or my configuration what causes this
behavior, but if I'm going back to this specific commit:
commit 74d3bd484fc0c79fd51302922c0eee8c3042fe14
Author: Nicolas Goaziou
Date: Sun Apr 17 17:00:14 2016 +0200
the org-mobile-push now creates the index.org correctly with the last
line as follows :
* [[file:test.org][test.org]]
So I see three possibilities: (1) I need to use a different emacs
configuration since this commit, (2) there is some bug in the code or
(3) I missed an important detail.
Thank you in advance for helping,
Martin
Re: [O] Bug: Feature Request: add 'org-babel-before-execute-hook' [8.3.4 (8.3.4-99-ga8e4a3-elpa @ /Users/macbookair/.emacs.d/elpa/org-20160704/)]
Yes this is not a bug and I have implemented this using advice: #+BEGIN_SRC emacs-lisp ;; See https://emacs-china.org/t/file/696 ;; And http://lists.gnu.org/archive/html/emacs-orgmode/2016-07/msg00136.html (defun check-file-exists-advice (orig-fun &optional arg info params) ;; Copied from ob-core.el. May not be compatible. (let* ((org-babel-current-src-block-location (or org-babel-current-src-block-location (nth 6 info) (org-babel-where-is-src-block-head) ;; inline src block (and (org-babel-get-inline-src-block-matches) (match-beginning 0 (info (if info (copy-tree info) (org-babel-get-src-block-info))) (merged-params (org-babel-merge-params (nth 2 info) params))) (when (cdr (assoc :file merged-params)) (unless (file-exists-p (cdr (assoc :file merged-params))) (error "File does not exist" (funcall orig-fun arg info params)) (advice-add 'org-babel-execute-src-block :around #'check-file-exists-advice) #+END_SRC And this is just a feature request: I’d love to implement this feature in another way. > On Jul 9, 2016, at 12:09 AM, Charles C. Berry wrote: > > On Fri, 8 Jul 2016, Jiajie Chen wrote: > [snip] > >> Now there exists 'org-babel-after-execute-hook'. I want to implement >> this functionality: Check whether the path specified in `:file' exists >> in file system and throw an error if that does not exists. If there is >> `org-babel-before-execute-hook', we can do that instead of using >> advice. I love symmetry :) >> > > Not a bug, of course. > > You can check on things like file existence in a number of ways. > > First, you can put emacs-lisp in header args, for example: > > This evaluates when there is a file called "elisp" in the default directory: > > #+header: :eval (or (file-exists-p "elisp") "no") > #+BEGIN_SRC emacs-lisp :eval (file-exists-p "elisp") > "got it!" > #+END_SRC > > > and this does not (when there is no 'lisp'): > > #+header: :eval (or (file-exists-p "lisp") "no") > #+BEGIN_SRC emacs-lisp > "got it!" > #+END_SRC > > I've illustrated here with `:eval', but `:file' will also take such an elisp > snippet. > > > Alternatively, you can define a function for `org-confirm-babel-evaluate' > that will block evaluation. > > Chuck
Re: [O] links-9.0 v3
K
On Friday, July 8, 2016, Nicolas Goaziou wrote:
> John Kitchin > writes:
>
> > Here are the new revisions that implement the previous solution you
> > suggested and that incorporate the commit merges as far as I can see.
>
> Thank you.
>
> > +(defcustom org-link-parameters
> > + '(("file" :complete 'org-file-complete-link)
>
> #'org-file-complete-link
>
> > +("file+emacs" :follow (lambda (path) (org-open-file path '(4
> > +("file+sys" :follow (lambda (path) (org-open-file path 'system)))
>
> This will ignore so-called "option" part, e.g.
>
> [[file:test.org::3]]
>
> :follow functions need to extract it somehow.
Good catch. I can probably do that tomorrow. Thanks!
>
> Once this issue is resolved, I think the whole change-set can be pushed
> to master, AFAIC.
>
--
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
[O] Dynamic links
Hi-
I've implemented "dynamic links" which are like plain links but for
arbitrary regular expressions.
I was wondering if there was a better way to do this?
You can see the implementation here:
https://github.com/sri/dotfiles/commit/cd3429ce0c8e637c803835299c2ed4653d19a5fb
(This works with Org-mode version: 8.3.4 - 8.3.4-88-g792bb9-elpa.)
With this config:
(add-to-list 'my-org-dynamic-links-matcher
'("\\([[:alpha:]]\\{2,5\\}-[[:digit:]]+\\)"
"https://some-ticketing-system.org/%s";))
a string like `TEST-122' is turned into a link, as you type it in.
And when you click on that link, it'll visit this URL:
https://some-ticketing-system.org/TEST-122
There are some things that gave me problems:
- I can't hit and have it follow the link. For this, it seems
like I would need to advice the `org-return' function.
- Despite the fact that the `TEST-123' has a `htmlize-link' text property,
it errors out with "No link found". To fix that, I needed to add a hook to
`org-open-at-point-functions'.
- I had to copy a bunch of code from `org-activate-plain-links' to get
this to work.
Thanks,
-Sriram
Re: [O] links-9.0 v3
John Kitchin writes:
> Here are the new revisions that implement the previous solution you
> suggested and that incorporate the commit merges as far as I can see.
Thank you.
> +(defcustom org-link-parameters
> + '(("file" :complete 'org-file-complete-link)
#'org-file-complete-link
> +("file+emacs" :follow (lambda (path) (org-open-file path '(4
> +("file+sys" :follow (lambda (path) (org-open-file path 'system)))
This will ignore so-called "option" part, e.g.
[[file:test.org::3]]
:follow functions need to extract it somehow.
Once this issue is resolved, I think the whole change-set can be pushed
to master, AFAIC.
Re: [O] links-9.0 v3
Hello, John Kitchin writes: > I don't understand what you mean here. The contents of org-link > protocols (in master) looks a lot like a list of (link-type :follow > :export), e.g. You're right. Keys in `org-link-protocols' are types. >> (nth 1 (assoc app org-link-protocols)) > > I see that these are not the same, since type != app. Per the above, this snippet from `org-open-at-point' is suspicious. > I was referring to the optional parameter, although I reconsider it > here. I don't understand how does the "application" get to the > follow functions of links other than file+sys and file+emacs. It seems > like we would need to allow type+application:path as a link syntax and > extend the link-parser to get the application. Right now it looks like > the parser only adds application properties to file type links. file+sys and file+emacs predate the parser. Since the manual doesn't seem to generalize them, parser support for them is rather minimalist. I really hope this syntax is not going to be extended, because it doesn't sound right to define the application opening a link at the syntax level. > I don't mind this (it makes links more flexible after all ;) OTOH, we > would have to "register" each type+application for the link regexp, and > then each type can have its own follow function, so it seems unnecessary > to me. I agree. As long as we need the regexp (because of plain links, actually), my suggestion is a false good idea. > My understanding of your statement of the problem is that the > link-parser recognizes file:path, file+sys:path, and file+emacs:path as > links of type "file", with different "application" properties. In the > implementation of org-open-at-point on master, there is a cond branch > for the "file" type link, and inside that the application is checked. > Hence, without your suggestion at the end, there is not a way to access > the :follow function of file+sys or file+emacs. > > To me this seems to be an unnecessary distinction from a link point of > view since those three file links could just be defined as regular links > with different follow/export functions. OTOH, perhaps there are other > places in org-mode that rely on being able to tell when a link is a > file, even if they are labeled file+sys or file+emacs that I am not > aware of? Any use not relying on :follow does not care above "+sys" or "+emacs". E.g., during export, file+sys and file+emacs are treated the same. > If I compare this to what exists in org-ref, for example, there > are close to 40 different types of citations one can use, but they are > all fundamentally "cite" types. They all share a common follow action, > but have different export functions. When defined as separate links, I > use them like cite:key citenum:key, citet:key, autocite:key, etc... > > Even here while I can see some utility for an application, e.g. perhaps > to open the key in zotero, or mendeley or bibtex, I would normally > associate that action with the :follow function. Am I missing > something? I think file+app was designed to override :follow function, so associating the action with the :follow function wouldn't help. > I only mentioned it because it seems to be in there in master via this line: > > (regexp-opt (cons "coderef" org-link-types) > > but it looks like it is in there in a different sort of way. It doesn't > seem important here. The line above creates a regexp matching types, as stored by the parser, as returned by (org-element-property :type link). This can be "coderef". OTOH (regexp-opt org-link-types) is meant to match links in an Org buffer, where there is no "coderef". Regards, -- Nicolas Goaziou
[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
> From: Robert Pluim > Cc: 23...@debbugs.gnu.org > Date: Fri, 08 Jul 2016 17:40:42 +0200 > > org-element--cache-after-change is: > > (defun org-element--cache-after-change (beg end pre) > "Update buffer modifications for current buffer. > BEG and END are the beginning and end of the range of changed > text, and the length in bytes of the pre-change text replaced by > that range. See `after-change-functions' for more information." > (when (org-element--cache-active-p) > (org-with-wide-buffer > (goto-char beg) > (beginning-of-line) > (save-match-data >(let ((top (point)) >(bottom (save-excursion (goto-char end) (line-end-position >;; Determine if modified area needs to be extended, according >;; to both previous and current state. We make a special >;; case for headline editing: if a headline is modified but >;; not removed, do not extend. >(when (case org-element--cache-change-warning >((t) t) >(headline > (not (and (org-with-limited-levels (org-at-heading-p)) > (= (line-end-position) bottom >(otherwise > (let ((case-fold-search t)) > (re-search-forward >org-element--cache-sensitive-re bottom t > ;; Effectively extend modified area. > (org-with-limited-levels > (setq top (progn (goto-char top) >(when (outline-previous-heading) (forward-line)) >(point))) > (setq bottom (progn (goto-char bottom) > (if (outline-next-heading) (1- (point)) > (point)) >;; Store synchronization request. >(let ((offset (- end beg pre))) > (org-element--cache-submit-request top (- bottom offset) offset) > ;; Activate a timer to process the request during idle time. > (org-element--cache-set-timer (current-buffer > > which already does save-match-data. If I globally disable the org > element cache by (setq org-element-use-cache nil) the issue > disappears, so now I'm confused as to what's going on. Load the file where this function lives as a .el file, and when the watchpoint triggers, show the results of "xbacktrace".
[O] Best approaches for implementing a developer workflow using ORG?
Hi,
As a developer I spend a lot of time moving back and forth between email
messages and COMMIT buffers copying and pasting review and signoff tags.
I've been investigating if there is anyway I can streamline this work
using org-mode.
The first step is fairly easy. When I come across an email that has
review comments or tags I can use org-capture to store a link under a
sub-heading of my reviews.org file:
#+name: capture-steps
#+begin_src emacs-lisp
(setq
org-capture-templates
'(
("g" "Save reference to review tag"
checkitem
(file+headline "review.org" "Review Tags")
" - [ ] %a" :immediate-finish t)
("r" "Review Comment (email)"
checkitem
(file+headline "review.org" "Review Comments")
" - [ ] %a")))
(defvar my-dco-tag-re
(rx (: bol (zero-or-more (in blank));; fresh line
(any "RSTA") (one-or-more (in alpha "-")) "-by: ";; tag
(one-or-more (in alpha blank "<>@."));; person
eol))
"Regexp to match DCO style tag.")
(defun my-capture-review-tags ()
"Return a list of tags for current buffer"
(let ((tags))
(save-excursion
(goto-char (point-min))
(while (re-search-forward my-dco-tag-re (point-max) t)
(add-to-list 'tags (match-string-no-properties 0
tags))
(defun my-org-maybe-capture-review-tag ()
"Check buffer for DCO tags and if found queue a review comment."
(interactive)
(when (my-capture-review-tags)
(org-capture nil "g")))
(when (fboundp 'mu4e-view-mode-map)
(define-key mu4e-view-mode-map (kbd "C-c C-c")
'my-org-maybe-capture-review-tag))
#+end_src
My stumbling block is now how do I approach automating the application
of tags when I'm in a magit COMMIT buffer. After some fumbling about I
can navigate my org file and find links that match a given patch title
(which generally matches the email title as they start as
git-send-email patch series):
#+name: automating-tag-fetching
#+begin_src emacs-lisp
(defun my-org-get-elements (file heading)
"Search FILE for HEADING and return the AST of that heading."
(interactive)
(let ((org-buf (org-capture-target-buffer file)))
(with-current-buffer org-buf
(org-element-map (org-element-parse-buffer) 'headline
(lambda (hl)
(when (string-match heading (org-element-property :raw-value hl))
(identity hl)))
(defun my-org-get-unchecked-items (items)
"Return the AST of unchecked ITEMS."
(org-element-map items 'item
(lambda (item) (when (eq (org-element-property :checkbox item) 'off)
(org-element-contents item)
(defun my-org-visit-link-and-snarf-tags ()
"Visit org-link-at-point and return a set of tags."
(save-window-excursion
(save-excursion
(org-open-at-point t)
(my-capture-review-tags
(defun my-org-find-review-tags (subject)
"Search saved review tags, looking for `SUBJECT' match."
(interactive)
(let* ((ast (my-org-get-elements "review.org" "Review Tags"))
(buffer (org-capture-target-buffer "review.org"))
(unchecked (my-org-get-unchecked-items ast))
(tags))
(org-element-map unchecked 'link
(lambda (link)
(let ((beg (org-element-property :begin link))
(end (org-element-property :end link)))
(with-current-buffer buffer
(when (string-match-p
subject
(buffer-substring-no-properties beg end))
(add-to-list 'tags
(my-org-visit-link-and-snarf-tags)))
(when tags
(mapconcat 'symbol-name tags "\n"
#+end_src
I'm not sure if my parsing of the tree is as efficient as it should
be, especially the manual grubbing about with :begin and :end of link
to match the link subject.
However the main problem is my-org-visit-link-and-snarf-tags doesn't
work as expected because there doesn't seem to be a way to visit an
org-link in the background to gather the data I need. Really I want to
visit the resulting buffer that org-open-at-point visits in a
(with-current-buffer &body) style visit.
I have tried the other option of inserting the tags as data for the
capture by doing a kill-new and a template like:
#+name: alternative-template
#+begin_src emacs-lisp
(setq
org-capture-templates
'(
("g" "Save reference to review tag"
checkitem
(file+headline "review.org" "Review Tags")
" - [ ] %a\n%c" :immediate-finish t)
("r" "Review Comment (email)"
checkitem
(file+headline "review.org" "Review Comments")
" - [ ] %a")))
#+end_src
But that seemed to cause problems when capturing multiple checkbox
links in a row. Maybe there is some way to stuff some meta-data in the
link?
However ideally I'd like to solve the problem of programitically
following org-links as I'd like to automate the bringing up of review
comments when I doing re-basing.
Re: [O] Bug: Feature Request: add 'org-babel-before-execute-hook' [8.3.4 (8.3.4-99-ga8e4a3-elpa @ /Users/macbookair/.emacs.d/elpa/org-20160704/)]
On Fri, 8 Jul 2016, Jiajie Chen wrote: [snip] Now there exists 'org-babel-after-execute-hook'. I want to implement this functionality: Check whether the path specified in `:file' exists in file system and throw an error if that does not exists. If there is `org-babel-before-execute-hook', we can do that instead of using advice. I love symmetry :) Not a bug, of course. You can check on things like file existence in a number of ways. First, you can put emacs-lisp in header args, for example: This evaluates when there is a file called "elisp" in the default directory: #+header: :eval (or (file-exists-p "elisp") "no") #+BEGIN_SRC emacs-lisp :eval (file-exists-p "elisp") "got it!" #+END_SRC and this does not (when there is no 'lisp'): #+header: :eval (or (file-exists-p "lisp") "no") #+BEGIN_SRC emacs-lisp "got it!" #+END_SRC I've illustrated here with `:eval', but `:file' will also take such an elisp snippet. Alternatively, you can define a function for `org-confirm-babel-evaluate' that will block evaluation. Chuck
[O] Bug: Feature Request: add 'org-babel-before-execute-hook' [8.3.4 (8.3.4-99-ga8e4a3-elpa @ /Users/macbookair/.emacs.d/elpa/org-20160704/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Now there exists 'org-babel-after-execute-hook'. I want to implement this functionality: Check whether the path specified in `:file' exists in file system and throw an error if that does not exists. If there is `org-babel-before-execute-hook', we can do that instead of using advice. I love symmetry :) Emacs : GNU Emacs 25.1.50.1 (x86_64-apple-darwin15.5.0, NS appkit-1404.47 Version 10.11.5 (Build 15F34)) of 2016-07-03 Package: Org-mode version 8.3.4 (8.3.4-99-ga8e4a3-elpa @ /Users/macbookair/.emacs.d/elpa/org-20160704/)
Re: [O] Computing dates in properties?
On 8 July 2016 at 05:01, Jay Iyer wrote: > Is it possible to perform simple calculations in properties like in the > example below? If so, please provide pointers. > Thanks, > -jay > > ** Headline 1 > :PROPERTIES: > :CUSTOM_ID: headline_1 > :DATE: [2016-07-07 Thu] > :END: > > ** Headline 2 > :PROPERTIES: > :CUSTOM_ID: headline_2 > :DATE: [date from headline 1 + 3 days] > :END: One way would be to use org-capture's %^ and %(lisp-function-call) syntax. -- Phil Hudson http://hudson-it.ddns.net @UWascalWabbit PGP/GnuPG ID: 0x887DCA63
