[O] MobileOrg: index.org links files to the wrong folder

2016-07-08 Thread Martin Leduc

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/)]

2016-07-08 Thread Jiegec
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
  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

2016-07-08 Thread John Kitchin
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

2016-07-08 Thread Sriram Thaiyar
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

2016-07-08 Thread Nicolas Goaziou
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

2016-07-08 Thread Nicolas Goaziou
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

2016-07-08 Thread Eli Zaretskii
> 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?

2016-07-08 Thread Alex Bennée

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 ) 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.

It 

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/)]

2016-07-08 Thread Charles C. Berry

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/)]

2016-07-08 Thread Jiajie Chen

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?

2016-07-08 Thread Philip Hudson
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