Re: [O] Links to LaTeX equations

[Carsten Dominik]

On Fri, Jun 28, 2019 at 4:46 PM Fraga, Eric  wrote:

> On Friday, 28 Jun 2019 at 11:58, Ken Mankoff wrote:
> > Why don't you define the link in Org?
> >
> > #+NAME: eq:foo
> > \begin{equation}
>
> And why are the obvious solutions not those that come to mind (for
> me)
>
> Many thanks.  Nothing in the documentation to even suggest this
> possibility.  That's my excuse. :)
>

It kind-of is documented, in section 4.2.  Is that unclear?

Carsten


> --
> : Professor Eric S Fraga, http://www.homepages.ucl.ac.uk/~ucecesf
> : Required hieroglyphics follow: ∀ε>0,∃δ>0∋|x-x₀|<δ⇒|f(x)-f(x₀)|<ε
>

Re: [O] Links in Org-mode : Clunky

[Ihor Radchenko]

Dear Nathan,

> Has anyone coded such a plugin or am I missing some cool Helm-fu?

Not exactly the same, but see the code below. Note that the code does
not support creating CUSTOM_ID. Instead, it silently creates an ID if it
does not exist (see (org-id-get ... 'create)).
The helm completion will work if it is enabled globally. 

#+begin_src emacs-lisp
(defvar org-id-history nil
  "ID completion history for id: link type.")

(defvar org-id-cache nil
  "ID completion cache for id: link type.")

(defun org-id-prompt-id ()
  "Prompt for the id during completion of att-id: link."
  (let ((org-refile-history org-id-history)
(org-refile-cache org-id-cache)
(org-refile-target-verify-function nil))
(let ((prompt-ans (org-refile-get-location "Select org entry")))
  (prog1
  (or (org-id-get (seq-find #'markerp
prompt-ans)
  'create)
  (user-error "Cannot find ID of the entry: %s" prompt-ans))
(setq org-id-history org-refile-history)
(setq org-id-cache org-refile-cache)


(defun org-id-link-complete ( arg)
  "Completion function for id: link."
  (let* ((id (org-id-prompt-id)))
(format "id:%s" id)))

(org-link-set-parameters "id" 
 :complete #'org-id-link-complete)
#+end_src

Regards,
Ihor
 


Nathan Neff  writes:

> Hello all,
>
> I've always found that the links in org-mode are basically
> very clunky to try to use in a quick fashion.
>
> To my understanding (see my other question about CUSTOM_ID
> versus ID) it's a good practice to store either a CUSTOM_ID or ID
> - (still can't grok the difference) and then store a hyperlink to that
> CUSTOM_ID or ID.
>
> By storing a hyperlink to CUSTOM_ID or ID my heading can change,
> but this won't matter.  I can also move the heading to another file, and
> links
> to it will still work.
>
> However, I find that it's pretty clunky to store a CUSTOM_ID or ID
> for a heading, and then copy the link, and then paste it where I want to
> use it.  Granted, it's not very difficult using org-store-link and
> org-insert-link,
> but it's just not as easy as I would think it would be.
>
> I've recently stumbled on Helm and was wondering if anyone has coded some
> kind of function that would show me a list of my headings, and create a
> CUSTOM_ID
> or ID for the heading and then copy a link to that heading so that I could
> easily paste it.
>
> Let's say I'm typing some stuff and want to insert a link to another
> heading, I would
> press some key combo and a helm search would come up.  I would find the
> heading that
> I want to link to.  If the heading has a CUSTOM_ID property, then a link to
> that CUSTOM_ID
> would be inserted at the text where my cursor is.  If there's not a
> CUSTOM_ID property perhaps a prompt for a CUSTOM_ID could pop up.  Once I
> enter the CUSTOM_ID, the link is created and copied to my cursor location /
> clipboard.
>
> Has anyone coded such a plugin or am I missing some cool Helm-fu?
>
> Thanks,
> --Nate

[O] Links in Org-mode : Clunky

[Nathan Neff]

Hello all,

I've always found that the links in org-mode are basically
very clunky to try to use in a quick fashion.

To my understanding (see my other question about CUSTOM_ID
versus ID) it's a good practice to store either a CUSTOM_ID or ID
- (still can't grok the difference) and then store a hyperlink to that
CUSTOM_ID or ID.

By storing a hyperlink to CUSTOM_ID or ID my heading can change,
but this won't matter.  I can also move the heading to another file, and
links
to it will still work.

However, I find that it's pretty clunky to store a CUSTOM_ID or ID
for a heading, and then copy the link, and then paste it where I want to
use it.  Granted, it's not very difficult using org-store-link and
org-insert-link,
but it's just not as easy as I would think it would be.

I've recently stumbled on Helm and was wondering if anyone has coded some
kind of function that would show me a list of my headings, and create a
CUSTOM_ID
or ID for the heading and then copy a link to that heading so that I could
easily paste it.

Let's say I'm typing some stuff and want to insert a link to another
heading, I would
press some key combo and a helm search would come up.  I would find the
heading that
I want to link to.  If the heading has a CUSTOM_ID property, then a link to
that CUSTOM_ID
would be inserted at the text where my cursor is.  If there's not a
CUSTOM_ID property perhaps a prompt for a CUSTOM_ID could pop up.  Once I
enter the CUSTOM_ID, the link is created and copied to my cursor location /
clipboard.

Has anyone coded such a plugin or am I missing some cool Helm-fu?

Thanks,
--Nate

Re: [O] Links to LaTeX equations

[John Kitchin]

Org-ref provides a ref link for exactly this purpose. It looks like
ref:an-equation and if you click on it it jumps to the label. The link is
red if the label doesn't exist and maroonish if it does. It exports in
latex as \ref{an-equation}. It sounds like just what you need.

You can get org-ref on melpa.

On Fri, Jun 28, 2019 at 9:15 AM Fraga, Eric  wrote:

> Hello all,
>
> it's that time of year where I have to think about revamping my lecture
> slides (having just finished one year, the next one starts...).  I write
> these in org and export to beamer obviously!
>
> I teach a technical subject.  I therefore have quite a few equations in
> my slides and I use LaTeX for these.  I would like to be able to use org
> fully with respect to links and targets.  If I define a label in LaTeX
> directly, \label{an-equation} for instance, I get no benefit from using
> an org link to it, e.g. [[an-equation]] (by default, this leads to the
> org exporter complaining about a missing target and if I tell org not to
> complain I subsequently miss real errors).  So I use inline LaTeX to
> provide the link, as in \ref{an-equation}.  But then I lose the ability
> to jump to the target within org, something which is quite useful given
> that I have many slides for the full module I teach.
>
> The only satisfactory solution I have found is to do something along
> these lines:
>
> #+begin_src org
>   The equation is:
>   ,#+begin_equation
>   <>
>   y = x + 3
>   ,#+end_equation
>
>   (later) In equation [[an-equation]], we see nothing much.
> #+end_src
>
> This works in that I can jump to the label by clicking on the link but I
> lose the ability to edit the equation in LaTeX mode.
>
> Any pointers would be welcome.
>
> Thanks,
> eric
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-379-g1b74ae
>
-- 
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

Re: [O] Links to LaTeX equations

[Fraga, Eric]

On Friday, 28 Jun 2019 at 10:19, John Kitchin wrote:
> Org-ref provides a ref link for exactly this purpose. 

Thanks John.  I've looked at org-ref before and it looks nice.  However,
due to my organically grown org (and Emacs) customizations (over 35
years...), I couldn't get it to work well for me.  Yes, I must clean up
my .emacs some day!

Using #+name: does the job for the moment.

Thanks again,
eric

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-379-g1b74ae

Re: [O] Links to LaTeX equations

[Ken Mankoff]

Hi Eric,

On 2019-06-28 at 10:55 -02, Fraga, Eric  wrote...
> I would like to be able to use org fully with respect to links and
> targets. If I define a label in LaTeX directly, \label{an-equation}
> for instance, I get no benefit from using an org link to it, e.g.
> [[an-equation]]

Why don't you define the link in Org?

#+NAME: eq:foo
\begin{equation}
foo
\end{equation}

  -k.

Re: [O] Links to LaTeX equations

[Fraga, Eric]

On Friday, 28 Jun 2019 at 11:58, Ken Mankoff wrote:
> Why don't you define the link in Org?
>
> #+NAME: eq:foo
> \begin{equation}

And why are the obvious solutions not those that come to mind (for
me)

Many thanks.  Nothing in the documentation to even suggest this
possibility.  That's my excuse. :)
-- 
: Professor Eric S Fraga, http://www.homepages.ucl.ac.uk/~ucecesf
: Required hieroglyphics follow: ∀ε>0,∃δ>0∋|x-x₀|<δ⇒|f(x)-f(x₀)|<ε

[O] Links to LaTeX equations

[Fraga, Eric]

Hello all,

it's that time of year where I have to think about revamping my lecture
slides (having just finished one year, the next one starts...).  I write
these in org and export to beamer obviously!

I teach a technical subject.  I therefore have quite a few equations in
my slides and I use LaTeX for these.  I would like to be able to use org
fully with respect to links and targets.  If I define a label in LaTeX
directly, \label{an-equation} for instance, I get no benefit from using
an org link to it, e.g. [[an-equation]] (by default, this leads to the
org exporter complaining about a missing target and if I tell org not to
complain I subsequently miss real errors).  So I use inline LaTeX to
provide the link, as in \ref{an-equation}.  But then I lose the ability
to jump to the target within org, something which is quite useful given
that I have many slides for the full module I teach.

The only satisfactory solution I have found is to do something along
these lines:

#+begin_src org
  The equation is:
  ,#+begin_equation
  <>
  y = x + 3
  ,#+end_equation

  (later) In equation [[an-equation]], we see nothing much.
#+end_src

This works in that I can jump to the label by clicking on the link but I
lose the ability to edit the equation in LaTeX mode.

Any pointers would be welcome.

Thanks,
eric

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-379-g1b74ae

Re: [O] Links for getting email in Gmail (IMAP) with Gnus ?

[Joseph Vidal-Rosset]

Le mar.  13 nov. 2018 à  09:36:17 , Eric S  Fraga  a
envoyé ce message:
> On Saturday, 10 Nov 2018 at 22:09, Joseph Vidal-Rosset wrote:
>> Hello,
>>
>> I know that it is possible to link emails in Todo list, but I meet
>> difficulties with Gmail IMAP and Gnus when the mail is in the box "All
>> emails" ("Tous les messages" in French): as soon as the email is in this
>> Archive, the link is broken and Gnus does not fetch it.
>
> Instead of reading your gmail messages in the Inbox, you could read them
> in the All mail group instead and link to emails in that group?
> Alternatively, don't archive your emails.

Many  thanks Eric  for  your  suggestion, but  finally,  I succeeded  in
writing a code that makes the job. I am going to give it to the list, it
could be helpful for others. Here it is (in my scimax/user/user.el):


#+BEGIN_SRC emacs-lisp
;;capture todo items using C-c c t
(define-key global-map (kbd "C-c c") 'org-capture)
(setq org-capture-templates
  '(("t" "todo" entry (file+headline "~/Dropbox/Orgzly/todo.org" "Tasks")
 "* TODO [#A] %?")))

(setq org-capture-templates
  '(("t" "todo" entry (file+headline "~/Dropbox/Orgzly/todo.org" "Tasks")
 "* TODO [#A] %?\nSCHEDULED: %(org-insert-time-stamp (org-read-date nil 
t \"+0d\"))\n")
 ("m" "TODO from Mail" entry (file+headline "~/Dropbox/Orgzly/todo.org" 
"Tasks") 
 "* TODO [#A] %?\n Voir l'email du %(org-insert-time-stamp (org-read-date 
nil t \"+0d\"))\n* LINK %a")
))

(defun hs/replace ()
   (interactive)
   (goto-char 1)
 (let ((search-invisible t)) (replace-string "gnus:INBOX#" 
"gnus:%5BGmail%5D/Tous les messages#"))) 
#+END_SRC

Note that %5B codes [  and that %5D codes ] . 

As  soon as  the Todo  note is  in my  todo.org, the  email is  linked
correctly and can be put in "Tous les messages" folder. 

I have now another small problem  to write a convenient kbd to archive
items once they are done, if I  do not succeed to find the solution, I
will write again to the list. 

Best wishes, 

-- 
Joseph 

[O] Links for getting email in Gmail (IMAP) with Gnus ?

[Joseph Vidal-Rosset]

Hello,

I know that it is possible to link emails in Todo list, but I meet
difficulties with Gmail IMAP and Gnus when the mail is in the box "All
emails" ("Tous les messages" in French): as soon as the email is in this
Archive, the link is broken and Gnus does not fetch it.

Help and code are welcome.

Best wishes,

Jo.

Re: [O] links cause table misalignment

[Nicolas Goaziou]

Thomas P  writes:

> Curious. Not even if you set your cursor on the a and press TAB again? (I 
> sometimes have to do it twice).
>
> This is what I did:
>
> Downloaded https://orgmode.org/org-9.1.9.zip and unzipped to ~/tmp/org-9.1.9
>
> Ran:
> emacs -Q
>
> In the scratch-buffer:
>   (add-to-list 'load-path "~/tmp/org-9.1.9/lisp")
>   (require 'org)
>
> Switched to a new buffer and did
> M-x org-mode RET
>
> Now if I enter that table (e.g. by copy-pasting from my earlier email)
> and align it, the table becomes misaligned for me when I press TAB
> when cursor is on the link "a".

I did the following, from a fresh Emacs, with :

(find-file "/tmp/bug-align.org")

(insert "| aa | aa |
| [[a][a]] | |
")

(search-backward "a][")

(org-table-align)

without being able to reproduce your issue.

I also tried searching backward for "][" instead, without any luck
either.

I tried in both master and maint.

Re: [O] links cause table misalignment

[Thomas P]

Curious. Not even if you set your cursor on the a and press TAB again? (I 
sometimes have to do it twice).

This is what I did:

Downloaded https://orgmode.org/org-9.1.9.zip and unzipped to ~/tmp/org-9.1.9

Ran:
emacs -Q

In the scratch-buffer:
  (add-to-list 'load-path "~/tmp/org-9.1.9/lisp")
  (require 'org)

Switched to a new buffer and did
M-x org-mode RET

Now if I enter that table (e.g. by copy-pasting from my earlier email) and 
align it, the table becomes misaligned for me when I press TAB when cursor is 
on the link "a".

I think I'm gonna try to reproduce it with org-mode versions between 8.2.10 and 
9.1.9, see what happens.

Från: Nicolas Goaziou 
Skickat: den 7 april 2018 09:38
Till: Thomas P
Kopia: emacs-orgmode@gnu.org
Ämne: Re: links cause table misalignment

Hello,

Thomas P  writes:

> With org-mode 9.1.9, my tables sometimes become misaligned when I press TAB 
> and the cursor is in a cell with a link.
>
> In an org-mode buffer, enter:
>
> | aa | aa |
> | [[a][a]] | |
>
> The lower-left cell becomes misaligned when I press TAB and the cursor
> is on the link "a".

FWIW, I cannot reproduce it. The table is correctly aligned.

Regards,

--
Nicolas Goaziou

Re: [O] links cause table misalignment

[Nicolas Goaziou]

Hello,

Thomas P  writes:

> With org-mode 9.1.9, my tables sometimes become misaligned when I press TAB 
> and the cursor is in a cell with a link.
>
> In an org-mode buffer, enter:
>
> | aa | aa |
> | [[a][a]] | |
>
> The lower-left cell becomes misaligned when I press TAB and the cursor
> is on the link "a".

FWIW, I cannot reproduce it. The table is correctly aligned.

Regards,

-- 
Nicolas Goaziou

[O] links cause table misalignment

[Thomas P]

Hello,

With org-mode 9.1.9, my tables sometimes become misaligned when I press TAB and 
the cursor is in a cell with a link.

In an org-mode buffer, enter:

| aa | aa |
| [[a][a]] | |

The lower-left cell becomes misaligned when I press TAB and the cursor is on 
the link "a".

I get no misalignment with org-mode 8.2.10.

emacs-version: GNU Emacs 25.3.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 
2017-09-12

Regards,
Thomas

Re: [O] links to id:

[Adam Porter]

I'm a bit confused by your description of the problem.  Could you
describe it again with explicit reproduction steps?

[O] links to id:

[kevinbanjo]

I've moved my .org-id-locations file into cloud storage (similar to a
dropbox folder).   I set the org-id-locations-file to point to that file.
I set up a link to the id.  It works fine for that one session of emacs.
After I quit and restart, then I click on the link it says it can't be
found and asks me if I want to create a new header.  It won't find the link
again until I run the function

(org-id-update-id-locations)

Then its all good again for the session.

Any idea why?

Also after it jumps to the link its REAL slow.   It just hangs for maybe 30
seconds.

Help!

Re: [O] links-9.0 v3

[John Kitchin]

Sounds good. Thanks for your patience, I learned a lot doing this! I
look forward to using it in the wild ;)

Nicolas Goaziou writes:

> John Kitchin  writes:
>
>> Ok. I have attached 20 patches with the updates below.
>
> Applied, with minor tweaks (trailing white spaces and too wide lines).
> Thank you for all this work.
>
> Ultimately, I removed `org--open-file-link' altogether since default
> behaviour for file+apps links DTRT. I also started to deprecate
> file+apps links, i.e., they are still supported but we start suggesting
> to use plain "file" links instead.
>
> Regards,


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

Re: [O] links-9.0 v3

[Nicolas Goaziou]

John Kitchin  writes:

> Ok. I have attached 20 patches with the updates below.

Applied, with minor tweaks (trailing white spaces and too wide lines).
Thank you for all this work.

Ultimately, I removed `org--open-file-link' altogether since default
behaviour for file+apps links DTRT. I also started to deprecate
file+apps links, i.e., they are still supported but we start suggesting
to use plain "file" links instead.

Regards,

Re: [O] links-9.0 v3

[John Kitchin]

Nicolas Goaziou writes:

> John Kitchin  writes:
>
>> I am not sure what you mean for this. Let me know if it isn't fixed in
>> the attached patches. I thought I had squashed everything into a concise
>> history.
>
> No worries. Let's just apply the 21 patches.

Ok. I have attached 20 patches with the updates below.

>
>> I think this code below (which should be in the patches) handles the
>> option correctly.
>>
>> (defun org--open-file-link (path app)
>
> It should, but I didn't see it in the previous patch, hence my remark.
>
>> -(defvar org-store-link-functions nil
>> -  "List of functions that are called to create and store a link.
>>  Each function will be called in turn until one returns a non-nil
>> -value.  Each function should check if it is responsible for creating
>> -this link (for example by looking at the major mode).
>> -If not, it must exit and return nil.
>> -If yes, it should return a non-nil value after a calling
>> -`org-store-link-props' with a list of properties and values.
>> -Special properties are:
>> +value.  Each function should check if it is responsible for
>> +creating this link (for example by looking at the major mode).  If
>> +not, it must exit and return nil.  If yes, it should return a
>> +non-nil value after a calling `org-store-link-props' with a list
>> +of properties and values. Special properties are:
>
> Missing a space after the full stop above.
>
>> +(defun org--open-file-link (path app)
>> +  "Open PATH using APP.
>> +
>> +PATH is from a file link, and can have the following syntax:
>> + [[file:~/code/main.c::255]]
>> + [[file:~/xx.org::My Target]]
>> + [[file:~/xx.org::*My Target]]
>> + [[file:~/xx.org::#my-custom-id]]
>> + [[file:~/xx.org::/regexp/]]
>> +
>> +APP is '(4) to open the PATH in Emacs, or 'system to use a system
>> application."
>
> Maybe something like:
>
>   Called it with \\[universal-argument] to open PATH in Emacs. If ARG is
>   `system', use a system application instead.
>
>
> Regards,
>From 9255b7f7b5462a82fb720720fc10eb5a1bd17297 Mon Sep 17 00:00:00 2001
From: John Kitchin 
Date: Thu, 7 Jul 2016 09:58:29 -0400
Subject: [PATCH 01/20] Create `org-link-parameters'

* lisp/org-element.el: Replace `org-link-types' variable with
  `org-link-types' function.

* lisp/org.el: Replace the `org-link-types' variable with
  `org-link-types' function. Create `org-link-get-parameter' and
  `org-link-set-parameters' functions. Remove `org-add-link-type'. Add
  `org-store-link-functions' function and remove
  `org-store-link-functions' variable. Add `org--open-file-link' for use
  as a :follow function for file type links.

* lisp/org.el: Set :follow functions for file links in `org-link-parameters.
Define `org-open-file-link' that opens a file link with an app.

* testing/lisp/test-ox.el: Remove usage of the `org-link-types'
  variable.

* lisp/org-compat.el: Move `org-add-link-type' and mark it as obsolete.

* lisp/ox.el: Change org-add-link-type comment in ox.el.
---
 lisp/org-compat.el  |  31 +
 lisp/org-element.el |   4 +-
 lisp/org.el | 168 
 lisp/ox.el  |   2 +-
 testing/lisp/test-ox.el |  16 ++---
 5 files changed, 156 insertions(+), 65 deletions(-)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 92fdb1c..a856ff7 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -374,6 +374,37 @@ Implements `define-error' for older emacsen."
 (put name 'error-conditions
 	 (copy-sequence (cons name (get 'error 'error-conditions))
 
+(defun org-add-link-type (type  follow export)
+  "Add a new TYPE link.
+FOLLOW and EXPORT are two functions.
+
+FOLLOW should take the link path as the single argument and do whatever
+is necessary to follow the link, for example find a file or display
+a mail message.
+
+EXPORT should format the link path for export to one of the export formats.
+It should be a function accepting three arguments:
+
+  paththe path of the link, the text after the prefix (like \"http:\")
+  descthe description of the link, if any
+  format  the export format, a symbol like `html' or `latex' or `ascii'.
+
+The function may use the FORMAT information to return different values
+depending on the format.  The return value will be put literally into
+the exported file.  If the return value is nil, this means Org should
+do what it normally does with links which do not have EXPORT defined.
+
+Org mode has a built-in default for exporting links.  If you are happy with
+this default, there is no need to define an export function for the link
+type.  For a simple example of an export function, see `org-bbdb.el'.
+
+If TYPE already exists, update it with the arguments.
+See `org-link-parameters' for documentation on the other parameters."
+  (org-link-add type :follow follow :export export) 
+  (message "Created %s link." type))
+
+(make-obsolete 'org-add-link-type 

Re: [O] links-9.0 v3

[Nicolas Goaziou]

John Kitchin  writes:

> I am not sure what you mean for this. Let me know if it isn't fixed in
> the attached patches. I thought I had squashed everything into a concise
> history.

No worries. Let's just apply the 21 patches.

> I think this code below (which should be in the patches) handles the
> option correctly.
>
> (defun org--open-file-link (path app)

It should, but I didn't see it in the previous patch, hence my remark.

> -(defvar org-store-link-functions nil
> -  "List of functions that are called to create and store a link.
>  Each function will be called in turn until one returns a non-nil
> -value.  Each function should check if it is responsible for creating
> -this link (for example by looking at the major mode).
> -If not, it must exit and return nil.
> -If yes, it should return a non-nil value after a calling
> -`org-store-link-props' with a list of properties and values.
> -Special properties are:
> +value.  Each function should check if it is responsible for
> +creating this link (for example by looking at the major mode).  If
> +not, it must exit and return nil.  If yes, it should return a
> +non-nil value after a calling `org-store-link-props' with a list
> +of properties and values. Special properties are:

Missing a space after the full stop above.

> +(defun org--open-file-link (path app)
> +  "Open PATH using APP.
> +
> +PATH is from a file link, and can have the following syntax:
> + [[file:~/code/main.c::255]]
> + [[file:~/xx.org::My Target]]
> + [[file:~/xx.org::*My Target]]
> + [[file:~/xx.org::#my-custom-id]]
> + [[file:~/xx.org::/regexp/]]
> +
> +APP is '(4) to open the PATH in Emacs, or 'system to use a system
> application."

Maybe something like:

  Called it with \\[universal-argument] to open PATH in Emacs. If ARG is
  `system', use a system application instead.


Regards,

Re: [O] links-9.0 v3

[John Kitchin]

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> Here are my current suggestions for the org-link 9.0.
>
> Thank you.

I think I fixed the points you made in the previous email.

>
>> Let me know what the best way to send these might be. It looks like it
>> might be 21 patches right now.
>
> AFAIU, many among them introduce code that no longer exists in the final
> draft. It would be nice to make them disappear, using interactive
> rebasing, as suggested earlier in this thread.

I am not sure what you mean for this. Let me know if it isn't fixed in
the attached patches. I thought I had squashed everything into a concise
history. 

>
> If that's not possible, just send them over here, I'll apply them.
>
> BTW sent patch doesn't seem to include an option handler. Am I missing
> something?

What do you mean by an option handler?

Do you mean for this file:path::option

I think this code below (which should be in the patches) handles the
option correctly.

(defun org--open-file-link (path app)
  "Open PATH using APP.

PATH is from a file link, and can have the following syntax:
 [[file:~/code/main.c::255]]
 [[file:~/xx.org::My Target]]
 [[file:~/xx.org::*My Target]]
 [[file:~/xx.org::#my-custom-id]]
 [[file:~/xx.org::/regexp/]]

APP is '(4) to open the PATH in Emacs, or 'system to use a system application."
  (let* ((fields (split-string path "::")) 
 (option (and (cdr fields)
  (mapconcat #'identity (cdr fields) ""
(apply #'org-open-file
   (car fields)
   app
   (cond ((not option) nil)
 ((string-match-p "\\`[0-9]+\\'" option)
  (list (string-to-number option)))
 (t (list nil
  (org-link-unescape option)))


>
> Regards,

>From ddc863fc16b8fe4b430e2f86b7ad96a0e90219cc Mon Sep 17 00:00:00 2001
From: John Kitchin 
Date: Thu, 7 Jul 2016 09:58:29 -0400
Subject: [PATCH 01/20] Create `org-link-parameters'

* lisp/org-element.el: Replace `org-link-types' variable with
  `org-link-types' function.

* lisp/org.el: Replace the `org-link-types' variable with
  `org-link-types' function. Create `org-link-get-parameter' and
  `org-link-set-parameters' functions. Remove `org-add-link-type'. Add
  `org-store-link-functions' function and remove
  `org-store-link-functions' variable. Add `org--open-file-link' for use
  as a :follow function for file type links.

* lisp/org.el: Set :follow functions for file links in `org-link-parameters.
Define `org-open-file-link' that opens a file link with an app.

* testing/lisp/test-ox.el: Remove usage of the `org-link-types'
  variable.

* lisp/org-compat.el: Move `org-add-link-type' and mark it as obsolete.

* lisp/ox.el: Change org-add-link-type comment in ox.el.
---
 lisp/org-compat.el  |  31 +
 lisp/org-element.el |   4 +-
 lisp/org.el | 167 
 lisp/ox.el  |   2 +-
 testing/lisp/test-ox.el |  16 ++---
 5 files changed, 155 insertions(+), 65 deletions(-)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 92fdb1c..a856ff7 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -374,6 +374,37 @@ Implements `define-error' for older emacsen."
 (put name 'error-conditions
 	 (copy-sequence (cons name (get 'error 'error-conditions))
 
+(defun org-add-link-type (type  follow export)
+  "Add a new TYPE link.
+FOLLOW and EXPORT are two functions.
+
+FOLLOW should take the link path as the single argument and do whatever
+is necessary to follow the link, for example find a file or display
+a mail message.
+
+EXPORT should format the link path for export to one of the export formats.
+It should be a function accepting three arguments:
+
+  paththe path of the link, the text after the prefix (like \"http:\")
+  descthe description of the link, if any
+  format  the export format, a symbol like `html' or `latex' or `ascii'.
+
+The function may use the FORMAT information to return different values
+depending on the format.  The return value will be put literally into
+the exported file.  If the return value is nil, this means Org should
+do what it normally does with links which do not have EXPORT defined.
+
+Org mode has a built-in default for exporting links.  If you are happy with
+this default, there is no need to define an export function for the link
+type.  For a simple example of an export function, see `org-bbdb.el'.
+
+If TYPE already exists, update it with the arguments.
+See `org-link-parameters' for documentation on the other parameters."
+  (org-link-add type :follow follow :export export) 
+  (message "Created %s link." type))
+
+(make-obsolete 'org-add-link-type "org-link-add." "Org 9.0")
+
 (provide 'org-compat)
 
 ;;; org-compat.el ends here
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 269bc7d..9452641 100644
--- 

Re: [O] links-9.0 v3

[Nicolas Goaziou]

John Kitchin  writes:

> What do you think of this approach:
>
>  (defcustom org-link-parameters
> -  '(("file"  :complete 'org-file-complete-link)
> -("file+emacs" :follow (lambda (path) (org-open-file path '(4
> -("file+sys" :follow (lambda (path) (org-open-file path 'system)))
> +  '(("file"  :complete #'org-file-complete-link)
> +("file+emacs" :follow (lambda (path) (org-open-file-link path '(4
> +("file+sys" :follow (lambda (path) (org-open-file-link path 'system)))

It could work, but I suggest to rename it `org--open-file-link' or some
such, i.e., make it an internal function, because it could be confusing
with `org-open-link-from-string'.

>  ("http") ("https") ("ftp") ("mailto")
>  ("news") ("shell") ("elisp")
>  ("doi") ("message") ("help"))
> @@ -10732,6 +10732,30 @@ they must return nil.")
>  
>  (defvar org-link-search-inhibit-query nil) ;; dynamically scoped
>  (defvar clean-buffer-list-kill-buffer-names) ; Defined in midnight.el
> +
> +(defun org-open-file-link (path app)
> +  "Open PATH using APP.
> +
> +PATH is from a file link, and can have the following

missing "syntax"?

> + [[file:~/code/main.c::255]]
> + [[file:~/xx.org::My Target]]
> + [[file:~/xx.org::*My Target]]
> + [[file:~/xx.org::#my-custom-id]]
> + [[file:~/xx.org::/regexp/]]
> +
> +APP is '(4) to open the PATH in Emacs, or 'system to use a system 
> application."
> +  (let* ((fields (split-string path "::"))  
> +  (option (when (cdr fields)
> +(mapconcat 'identity (cdr fields) ""

(and (cdr field)
 (mapconcat #'identity (cdr fields) ""))
 
> +(apply #'org-open-file
> +(car fields)
> +app
> +(cond ((not option) nil)
> +  ((org-string-match-p "\\`[0-9]+\\'" option)

org-string-match-p -> string-match-p


Regards,

Re: [O] links-9.0 v3

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> Here are my current suggestions for the org-link 9.0.

Thank you.

> Let me know what the best way to send these might be. It looks like it
> might be 21 patches right now.

AFAIU, many among them introduce code that no longer exists in the final
draft. It would be nice to make them disappear, using interactive
rebasing, as suggested earlier in this thread.

If that's not possible, just send them over here, I'll apply them.

BTW sent patch doesn't seem to include an option handler. Am I missing 
something?

Regards,

-- 
Nicolas Goaziou

Re: [O] links-9.0 v3

[John Kitchin]

Here are my current suggestions for the org-link 9.0. Let me know what
the best way to send these might be. It looks like it might be 21
patches right now. Thanks,

17 files changed, 187 insertions(+), 87 deletions(-)
contrib/orgmanual.org |  27 +
doc/org.texi  |  27 +
etc/ORG-NEWS  |   2 +
lisp/org-bbdb.el  |   8 ++-
lisp/org-bibtex.el|   5 +-
lisp/org-docview.el   |   6 +-
lisp/org-element.el   |   4 +-
lisp/org-eshell.el|   5 +-
lisp/org-gnus.el  |   3 +-
lisp/org-id.el|   2 +-
lisp/org-info.el  |   8 ++-
lisp/org-irc.el   |   4 +-
lisp/org-mhe.el   |   3 +-
lisp/org-rmail.el |   3 +-
lisp/org-w3m.el   |   2 +-
lisp/org.el   | 163 ++
lisp/ox.el|   2 +-

modified   contrib/orgmanual.org
@@ -3300,12 +3300,16 @@ can define them in the file with
   ,#+LINK: googlehttp://www.google.com/search?q=%s
 #+end_src
 
-{{{noindent}}} In-buffer completion (see [[Completion]]) can be used after
-{{{samp([)}}} to complete link abbreviations.  You may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
+after {{{samp([)}}} to complete link abbreviations.  You may also
+define a function that implements special (e.g., completion) support
+for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
+should not accept any arguments, and return the full link with
+prefix.  You can set the link completion function like this:
+
+#+BEGIN_SRC emacs-lisp
+(org-link-set-parameter "type" :complete #'some-completion-function)
+#+END_SRC
 
 ** Search options
:PROPERTIES:
@@ -16998,10 +17002,9 @@ description when the link is later inserted into an 
Org buffer with
 {{{kbd(C-c C-l)}}}.
 
 When it makes sense for your new link type, you may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+function that implements special (e.g., completion) support for
+inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function should
+not accept any arguments, and return the full link with prefix.
 
 ** Context-sensitive commands
:PROPERTIES:
@@ -19181,8 +19184,8 @@ from the list of stored links.  To keep it in the list 
later use, use a
 triple {{{kbd(C-u)}}} prefix argument to {{{kbd(C-c C-l)}}}, or
 configure the option ~org-keep-stored-link-after-insertion~.
 
-[fn:37] This works by calling a special function
-~org-PREFIX-complete-link~.
+[fn:37] This works if a function has been defined in the :complete
+property of a link in ~org-link-parameters~.
 
 [fn:38] See the variable ~org-display-internal-link-with-indirect-buffer~.
 
modified   doc/org.texi
@@ -3711,11 +3711,11 @@ them with @key{up} and @key{down} (or @kbd{M-p/n}).
 valid link prefixes like @samp{http:} or @samp{ftp:}, including the prefixes
 defined through link abbreviations (@pxref{Link abbreviations}).  If you
 press @key{RET} after inserting only the @var{prefix}, Org will offer
-specific completion support for some link types@footnote{This works by
-calling a special function @code{org-PREFIX-complete-link}.}  For
-example, if you type @kbd{file @key{RET}}, file name completion (alternative
-access: @kbd{C-u C-c C-l}, see below) will be offered, and after @kbd{bbdb
-@key{RET}} you can complete contact names.
+specific completion support for some link types@footnote{This works if a
+completion function is defined in the :complete property of a link in
+@var{org-link-parameters}.}  For example, if you type @kbd{file @key{RET}},
+file name completion (alternative access: @kbd{C-u C-c C-l}, see below) will
+be offered, and after @kbd{bbdb @key{RET}} you can complete contact names.
 @orgkey C-u C-c C-l
 @cindex file name completion
 @cindex completion, of file names
@@ -3887,10 +3887,13 @@ can define them in the file with
 
 @noindent
 In-buffer completion (@pxref{Completion}) can be used after @samp{[} to
-complete link abbreviations.  You may also define a function
-@code{org-PREFIX-complete-link} that implements special (e.g., completion)
-support for inserting such a link with @kbd{C-c C-l}.  Such a function should
-not accept any arguments, and return the full link with prefix.
+complete link abbreviations.  You may also define a function that implements
+special (e.g., completion) support for inserting such a link with @kbd{C-c
+C-l}.  Such a function should not accept any arguments, and return the full
+link with prefix.  You can add a completion function to a link like this:
+
+@code{(org-link-set-parameters ``type'' :complete #'some-function)}
+
 
 @node Search 

Re: [O] links-9.0 v3

[John Kitchin]

What do you think of this approach:

 (defcustom org-link-parameters
-  '(("file"  :complete 'org-file-complete-link)
-("file+emacs" :follow (lambda (path) (org-open-file path '(4
-("file+sys" :follow (lambda (path) (org-open-file path 'system)))
+  '(("file"  :complete #'org-file-complete-link)
+("file+emacs" :follow (lambda (path) (org-open-file-link path '(4
+("file+sys" :follow (lambda (path) (org-open-file-link path 'system)))
 ("http") ("https") ("ftp") ("mailto")
 ("news") ("shell") ("elisp")
 ("doi") ("message") ("help"))
@@ -10732,6 +10732,30 @@ they must return nil.")
 
 (defvar org-link-search-inhibit-query nil) ;; dynamically scoped
 (defvar clean-buffer-list-kill-buffer-names) ; Defined in midnight.el
+
+(defun org-open-file-link (path app)
+  "Open PATH using APP.
+
+PATH is from a file link, and can have the following 
+ [[file:~/code/main.c::255]]
+ [[file:~/xx.org::My Target]]
+ [[file:~/xx.org::*My Target]]
+ [[file:~/xx.org::#my-custom-id]]
+ [[file:~/xx.org::/regexp/]]
+
+APP is '(4) to open the PATH in Emacs, or 'system to use a system application."
+  (let* ((fields (split-string path "::"))
+(option (when (cdr fields)
+  (mapconcat 'identity (cdr fields) ""
+(apply #'org-open-file
+  (car fields)
+  app
+  (cond ((not option) nil)
+((org-string-match-p "\\`[0-9]+\\'" option)
+ (list (string-to-number option)))
+(t (list nil
+ (org-link-unescape option)))
+
 (defun org-open-at-point ( arg reference-buffer)
   "Open link, timestamp, footnote or tags at point.


Nicolas Goaziou writes:

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


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

Re: [O] links-9.0 v3

[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

Re: [O] links-9.0 v3

[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

[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

Re: [O] links-9.0 v3

[John Kitchin]

Here are the new revisions that implement the previous solution you
suggested and that incorporate the commit merges as far as I can see.
WDYT?


commit 290213ef3eee86175d5a6b15c7b6173afd0c1616
Author: John Kitchin 
Date:   Tue Jul 5 10:38:42 2016 -0400

Update the contrib manual

diff --git a/contrib/orgmanual.org b/contrib/orgmanual.org
index e48ae97..07d9e8d 100644
--- a/contrib/orgmanual.org
+++ b/contrib/orgmanual.org
@@ -3300,12 +3300,16 @@ can define them in the file with
   ,#+LINK: googlehttp://www.google.com/search?q=%s
 #+end_src
 
-{{{noindent}}} In-buffer completion (see [[Completion]]) can be used after
-{{{samp([)}}} to complete link abbreviations.  You may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
+after {{{samp([)}}} to complete link abbreviations.  You may also
+define a function that implements special (e.g., completion) support
+for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
+should not accept any arguments, and return the full link with
+prefix.  You can set the link completion function like this:
+
+#+BEGIN_SRC emacs-lisp
+(org-link-set-parameter "type" :complete #'some-completion-function)
+#+END_SRC
 
 ** Search options
:PROPERTIES:
@@ -16998,10 +17002,9 @@ description when the link is later inserted into an 
Org buffer with
 {{{kbd(C-c C-l)}}}.
 
 When it makes sense for your new link type, you may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+function that implements special (e.g., completion) support for
+inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function should
+not accept any arguments, and return the full link with prefix.
 
 ** Context-sensitive commands
:PROPERTIES:
@@ -19181,8 +19184,8 @@ from the list of stored links.  To keep it in the list 
later use, use a
 triple {{{kbd(C-u)}}} prefix argument to {{{kbd(C-c C-l)}}}, or
 configure the option ~org-keep-stored-link-after-insertion~.
 
-[fn:37] This works by calling a special function
-~org-PREFIX-complete-link~.
+[fn:37] This works if a function has been defined in the :complete
+property of a link in ~org-link-parameters~.
 
 [fn:38] See the variable ~org-display-internal-link-with-indirect-buffer~.
 

commit 8e51c2ff4b37524dcc489d58a6769fd8430c5593
Author: John Kitchin 
Date:   Tue Jul 5 10:31:30 2016 -0400

Update NEWS with link announcement

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9909910..6ff7442 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -353,6 +353,8 @@ first footnote.
 *** The ~org-block~ face is inherited by ~src-blocks~
 This works also when =org-src-fontify-natively= is non-nil.  It is also
 possible to specify per-languages faces.  See the manual for details.
+*** Links are now customizable
+Links can now have custom colors, tooltips, keymaps, display behavior, etc... 
Links are now centralized in ~org-link-parameters~.
 ** New functions
 *** ~org-next-line-empty-p~
 It replaces the deprecated ~next~ argument to ~org-previous-line-empty-p~.

commit 246539109bac10f8de227adbc491bdeb94e80ba0
Author: John Kitchin 
Date:   Tue Jul 5 10:29:07 2016 -0400

Update the texinfo for link parameters documentation

diff --git a/doc/org.texi b/doc/org.texi
index e92788f..f962a58 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3711,11 +3711,11 @@ them with @key{up} and @key{down} (or @kbd{M-p/n}).
 valid link prefixes like @samp{http:} or @samp{ftp:}, including the prefixes
 defined through link abbreviations (@pxref{Link abbreviations}).  If you
 press @key{RET} after inserting only the @var{prefix}, Org will offer
-specific completion support for some link types@footnote{This works by
-calling a special function @code{org-PREFIX-complete-link}.}  For
-example, if you type @kbd{file @key{RET}}, file name completion (alternative
-access: @kbd{C-u C-c C-l}, see below) will be offered, and after @kbd{bbdb
-@key{RET}} you can complete contact names.
+specific completion support for some link types@footnote{This works if a
+completion function is defined in the :complete property of a link in
+@var{org-link-parameters}.}  For example, if you type @kbd{file @key{RET}},
+file name completion (alternative access: @kbd{C-u C-c C-l}, see below) will
+be offered, and after @kbd{bbdb @key{RET}} you can complete contact names.
 @orgkey C-u C-c C-l
 @cindex file name completion
 @cindex completion, of file names
@@ -3887,10 +3887,13 @@ can define them in the file with
 
 @noindent
 In-buffer completion (@pxref{Completion}) can be used 

Re: [O] links-9.0 v3

[John Kitchin]

Let me preface my reply that I think your last suggestion:

>   (org-link-get-parameter (if app (concat type "+" app) type) :follow)

Is the thing to do for this set of changes for now. I think it would
wrap up this set of changes. I will send a new set of diffs that
implement this shortly after this mail.

I have some other responses below because there are some things I don't
totally understand yet.

Nicolas Goaziou writes:

> John Kitchin  writes:
>
>>> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
>>> so, when checking `dedicated-function' first, we cannot tell the
>>> difference between "file+sys" and "file+emacs".
>>
>> I don't follow this. Why can't these be three types?
>
> The type is "file". "sys" or "emacs" are indications about how to follow
> them. "docview" is also an indication, but it really points to a "file".
>
>> They define 3 different follow actions right? Those are basically
>> equal to pressing RET, C-u RET and C-u C-u RET on a link. We could
>> just define three :follow functions, and one :export function for
>> them.
>
> It doesn't mean they cannot have an entry in `org-link-parameters'.
> Actually they should.
>
> However `org-link-protocols' keys are applications, not types. So

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.

#+BEGIN_SRC emacs-lisp :results code
(assoc "bbdb" org-link-protocols)
#+END_SRC

#+RESULTS:
#+BEGIN_SRC emacs-lisp
("bbdb" org-bbdb-open org-bbdb-export)
#+END_SRC

There doesn't seem to be a "sys" or "emacs" defined in
org-link-protocols in master. So there is no dedicated function being
called as far as I can tell.

#+BEGIN_SRC emacs-lisp :results code
(assoc "sys" org-link-protocols)
#+END_SRC

#+RESULTS:
#+BEGIN_SRC emacs-lisp
nil
#+END_SRC

>  (org-link-get-parameter type :follow)
>
> is not a drop-in replacement for
>
>   (nth 1 (assoc app org-link-protocols))

I see that these are not the same, since type != app.

With app, this would try to look up (org-link-get-parameter "sys"
:follow), which currently would return nil. That seems consistent with
what is currently in master too. I concede that if a "sys" link was
defined it would do something, but that isn't currently the case AFAICT.
Your solution solves this nicely though.

>> With the patches I sent, the three types actually work as they used to,
>> e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
>> ;), file+sys:some.pptx opens it in powerpoint. This seems to be because
>> org-element-context (via org-element-link-parser) sees file+sys and
>> file+emacs as a file type.
>
> Which is correct.
>
>> Overall, this is an inconsistency to me. On one hand, we need file+sys
>> and file+emacs in org-link-parameters so that they are built into the
>> link regexps (or they would have to be hard-coded in the function that
>> makes the regexp.
>
> [...]
>
>> On the other hand, the org-open-at-point
>> function bypasses the link properties, so it is not possible to change
>> the :follow function for file+sys and file+emacs.
>
> Of course it is possible. I suggested two solutions already.
>
>>> One solution is to swap the logic order. First, if app is non-nil, we
>>> use it. If it isn't, we look after `dedicated-function'.
>>>
>>> Another solution is to add an optional parameter to the signature of
>>> the :follow function, which would be the "app" (e.g. "emacs", "sys",
>>> "docview"...) to use. I tend to think this solution is slightly better,
>>> since it doesn't require to hard-code logic in `org-open-at-point'.
>>>
>>> WDYT?
>>
>> I am not crazy about this solution,
>
> Which one? I suggested two of them.
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.

>
>> since it only applies to one type of link,
>
> Does it? Every type can benefit from this change, i.e. instead of
> calling follow function with a single argument, it is called with two,
> the second one being the application (e.g., "sys", "emacs"...) or nil.

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 would leave this on the table for future consideration, but consider
it outside the current scope of this set of changes. I think with your
final suggestion it isn't necessary to consider this now. 

>
>> and I can't see how to use it for other follow functions. It would be
>> better IMO to define :follow functions maybe like this:
>>
>> "file" :follow 

Re: [O] links-9.0 v3

[Nicolas Goaziou]

John Kitchin  writes:

>> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
>> so, when checking `dedicated-function' first, we cannot tell the
>> difference between "file+sys" and "file+emacs".
>
> I don't follow this. Why can't these be three types?

The type is "file". "sys" or "emacs" are indications about how to follow
them. "docview" is also an indication, but it really points to a "file".

> They define 3 different follow actions right? Those are basically
> equal to pressing RET, C-u RET and C-u C-u RET on a link. We could
> just define three :follow functions, and one :export function for
> them.

It doesn't mean they cannot have an entry in `org-link-parameters'.
Actually they should.

However `org-link-protocols' keys are applications, not types. So

  (org-link-get-parameter type :follow)

is not a drop-in replacement for

  (nth 1 (assoc app org-link-protocols))

> With the patches I sent, the three types actually work as they used to,
> e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
> ;), file+sys:some.pptx opens it in powerpoint. This seems to be because
> org-element-context (via org-element-link-parser) sees file+sys and
> file+emacs as a file type.

Which is correct.

> Overall, this is an inconsistency to me. On one hand, we need file+sys
> and file+emacs in org-link-parameters so that they are built into the
> link regexps (or they would have to be hard-coded in the function that
> makes the regexp.

[...]

> On the other hand, the org-open-at-point
> function bypasses the link properties, so it is not possible to change
> the :follow function for file+sys and file+emacs.

Of course it is possible. I suggested two solutions already.

>> One solution is to swap the logic order. First, if app is non-nil, we
>> use it. If it isn't, we look after `dedicated-function'.
>>
>> Another solution is to add an optional parameter to the signature of
>> the :follow function, which would be the "app" (e.g. "emacs", "sys",
>> "docview"...) to use. I tend to think this solution is slightly better,
>> since it doesn't require to hard-code logic in `org-open-at-point'.
>>
>> WDYT?
>
> I am not crazy about this solution,

Which one? I suggested two of them.

> since it only applies to one type of link,

Does it? Every type can benefit from this change, i.e. instead of
calling follow function with a single argument, it is called with two,
the second one being the application (e.g., "sys", "emacs"...) or nil.

> and I can't see how to use it for other follow functions. It would be
> better IMO to define :follow functions maybe like this:
>
> "file" :follow #'org-open-at-point
> "file+sys" :follow (lambda (_) (org-open-at-point '(4)))
> "file+emacs" :follow (lambda (_) (org-open-at-point '(16)))
>
> and make them be honored in org-open-at-point. Then we could eliminate
> the logic code in org-open-at-point.

You may be misunderstanding the problem. 

The issue is that `org-open-at-point', at the moment, cannot call
the :follow function for "file+emacs" or "file+sys" since the common
type is "file", even if `org-link-parameters' distinguish them. IOW the
first :follow function would always be called.

Also, `org-open-at-point' shouldn't be part of a follow function, since
`org-open-at-point' calls follow functions. It can call `org-open-file',
tho, as currently done in `org-open-at-point'.

Actually, I can think of a third solution, which may well follow the
path of least resistance. Instead of calling

  (org-link-get-parameter type :follow)

we would call

  (org-link-get-parameter (if app (concat type "+" app) type) :follow)

and get the appropriate follow function. This solution is local to
`org-open-at-point', but I don't think other places need :follow
function.

>>>(let ((data (assoc type org-link-parameters)))
>>> -(if data
>>> -   (cl-loop for (key val) on parameters by #'cddr
>>> -do
>>> -(setf (cl-getf (cdr data) key)
>>> -  val))
>>> +(if data (setcdr data (org-combine-plists (cdr data) parameters))
>>>(push (cons type parameters) org-link-parameters)
>>>(org-make-link-regexps)
>>>(org-element-update-syntax
>>
>> This change can be merged with `org-link-set-parameters' definition.
>
> I am not sure how to do that. It is like a hunk in one commit that I
> want to move to another commit.

I would edit the commit defining `org-link-set-parameters' and install
that change there. Then, upon rebasing, I would make sure this change is
preserved.

>>> +(defcustom org-link-parameters
>>> +  '(("http") ("https") ("ftp") ("mailto")
>>> +("file" :complete 'org-file-complete-link)
>>> +("file+emacs") ("file+sys")
>>> +("news") ("shell") ("elisp")
>>> +("doi") ("message") ("help"))
>>
>> See above about "file+emacs" and "file+sys", which are not valid types.
>
> Those either need to be here for link regexps, or hard-coded somewhere
> else though.

Re: [O] links-9.0 v3

[John Kitchin]

>
> That's great. I realized there's one gotcha left.
>
>>(let* ((option (org-element-property :search-option link))
>>   (app (org-element-property :application link))
>>   (dedicated-function
>> -  (nth 1 (assoc app org-link-protocols
>> +  (org-link-get-parameter type :follow)))
>>  (if dedicated-function
>
> Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
> so, when checking `dedicated-function' first, we cannot tell the
> difference between "file+sys" and "file+emacs".

I don't follow this. Why can't these be three types? They
define 3 different follow actions right? Those are basically equal to
pressing RET, C-u RET and C-u C-u RET on a link. We could just define
three :follow functions, and one :export function for them.

With the patches I sent, the three types actually work as they used to,
e.g. file:some.pptx opens the powerpoint file in emacs (not convenient
;), file+sys:some.pptx opens it in powerpoint. This seems to be because
org-element-context (via org-element-link-parser) sees file+sys and
file+emacs as a file type.

Overall, this is an inconsistency to me. On one hand, we need file+sys
and file+emacs in org-link-parameters so that they are built into the
link regexps (or they would have to be hard-coded in the function that
makes the regexp. E.g. (cons "coderef" (org-link-types)) is already done
that way for some reason). On the other hand, the org-open-at-point
function bypasses the link properties, so it is not possible to change
the :follow function for file+sys and file+emacs.

> One solution is to swap the logic order. First, if app is non-nil, we
> use it. If it isn't, we look after `dedicated-function'.
>
> Another solution is to add an optional parameter to the signature of
> the :follow function, which would be the "app" (e.g. "emacs", "sys",
> "docview"...) to use. I tend to think this solution is slightly better,
> since it doesn't require to hard-code logic in `org-open-at-point'.
>
> WDYT?

I am not crazy about this solution, since it only applies to one type of
link, and I can't see how to use it for other follow functions. It would be
better IMO to define :follow functions maybe like this:

"file" :follow #'org-open-at-point
"file+sys" :follow (lambda (_) (org-open-at-point '(4)))
"file+emacs" :follow (lambda (_) (org-open-at-point '(16)))

and make them be honored in org-open-at-point. Then we could eliminate
the logic code in org-open-at-point.

>
>>(let ((data (assoc type org-link-parameters)))
>> -(if data
>> -(cl-loop for (key val) on parameters by #'cddr
>> - do
>> - (setf (cl-getf (cdr data) key)
>> -   val))
>> +(if data (setcdr data (org-combine-plists (cdr data) parameters))
>>(push (cons type parameters) org-link-parameters)
>>(org-make-link-regexps)
>>(org-element-update-syntax
>
> This change can be merged with `org-link-set-parameters' definition.

I am not sure how to do that. It is like a hunk in one commit that I
want to move to another commit.

>
>> +(defcustom org-link-parameters
>> +  '(("http") ("https") ("ftp") ("mailto")
>> +("file" :complete 'org-file-complete-link)
>> +("file+emacs") ("file+sys")
>> +("news") ("shell") ("elisp")
>> +("doi") ("message") ("help"))
>
> See above about "file+emacs" and "file+sys", which are not valid types.

Those either need to be here for link regexps, or hard-coded somewhere
else though. Speaking of which, should coderef be a link type, so it can
be removed as a hard-coded string that I referenced above?

> Regards,


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

Re: [O] links-9.0 v3

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> I think I have addressed these. Revised commits appended and at 
> https://github.com/jkitchin/org-mode/tree/link-9.0-v3.
>
> The new org-link-set-parameters function you suggested works fine as far
> as I can tell. WDYT?

That's great. I realized there's one gotcha left.

> (let* ((option (org-element-property :search-option link))
>(app (org-element-property :application link))
>(dedicated-function
> -   (nth 1 (assoc app org-link-protocols
> +   (org-link-get-parameter type :follow)))
>   (if dedicated-function

Here is the gotcha. `type' is "file", not "file+sys" or "file+emacs",
so, when checking `dedicated-function' first, we cannot tell the
difference between "file+sys" and "file+emacs".

One solution is to swap the logic order. First, if app is non-nil, we
use it. If it isn't, we look after `dedicated-function'.

Another solution is to add an optional parameter to the signature of
the :follow function, which would be the "app" (e.g. "emacs", "sys",
"docview"...) to use. I tend to think this solution is slightly better,
since it doesn't require to hard-code logic in `org-open-at-point'.

WDYT?

>(let ((data (assoc type org-link-parameters)))
> -(if data
> - (cl-loop for (key val) on parameters by #'cddr
> -  do
> -  (setf (cl-getf (cdr data) key)
> -val))
> +(if data (setcdr data (org-combine-plists (cdr data) parameters))
>(push (cons type parameters) org-link-parameters)
>(org-make-link-regexps)
>(org-element-update-syntax

This change can be merged with `org-link-set-parameters' definition.

> +(defcustom org-link-parameters
> +  '(("http") ("https") ("ftp") ("mailto")
> +("file" :complete 'org-file-complete-link)
> +("file+emacs") ("file+sys")
> +("news") ("shell") ("elisp")
> +("doi") ("message") ("help"))

See above about "file+emacs" and "file+sys", which are not valid types.

Regards,

-- 
Nicolas Goaziou

Re: [O] links-9.0 v3

[John Kitchin]

I think I have addressed these. Revised commits appended and at 
https://github.com/jkitchin/org-mode/tree/link-9.0-v3.

The new org-link-set-parameters function you suggested works fine as far
as I can tell. WDYT?

commit f8bb180150514b92535506601c747001da305610
Author: John Kitchin 
Date:   Tue Jul 5 10:38:42 2016 -0400

Update the contrib manual

diff --git a/contrib/orgmanual.org b/contrib/orgmanual.org
index e48ae97..07d9e8d 100644
--- a/contrib/orgmanual.org
+++ b/contrib/orgmanual.org
@@ -3300,12 +3300,16 @@ can define them in the file with
   ,#+LINK: googlehttp://www.google.com/search?q=%s
 #+end_src
 
-{{{noindent}}} In-buffer completion (see [[Completion]]) can be used after
-{{{samp([)}}} to complete link abbreviations.  You may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
+after {{{samp([)}}} to complete link abbreviations.  You may also
+define a function that implements special (e.g., completion) support
+for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
+should not accept any arguments, and return the full link with
+prefix.  You can set the link completion function like this:
+
+#+BEGIN_SRC emacs-lisp
+(org-link-set-parameter "type" :complete #'some-completion-function)
+#+END_SRC
 
 ** Search options
:PROPERTIES:
@@ -16998,10 +17002,9 @@ description when the link is later inserted into an 
Org buffer with
 {{{kbd(C-c C-l)}}}.
 
 When it makes sense for your new link type, you may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+function that implements special (e.g., completion) support for
+inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function should
+not accept any arguments, and return the full link with prefix.
 
 ** Context-sensitive commands
:PROPERTIES:
@@ -19181,8 +19184,8 @@ from the list of stored links.  To keep it in the list 
later use, use a
 triple {{{kbd(C-u)}}} prefix argument to {{{kbd(C-c C-l)}}}, or
 configure the option ~org-keep-stored-link-after-insertion~.
 
-[fn:37] This works by calling a special function
-~org-PREFIX-complete-link~.
+[fn:37] This works if a function has been defined in the :complete
+property of a link in ~org-link-parameters~.
 
 [fn:38] See the variable ~org-display-internal-link-with-indirect-buffer~.
 

commit d5db3a80b3e6eab98935a329d8633a85f398ee3a
Author: John Kitchin 
Date:   Tue Jul 5 10:31:30 2016 -0400

Update NEWS with link announcement

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9909910..6ff7442 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -353,6 +353,8 @@ first footnote.
 *** The ~org-block~ face is inherited by ~src-blocks~
 This works also when =org-src-fontify-natively= is non-nil.  It is also
 possible to specify per-languages faces.  See the manual for details.
+*** Links are now customizable
+Links can now have custom colors, tooltips, keymaps, display behavior, etc... 
Links are now centralized in ~org-link-parameters~.
 ** New functions
 *** ~org-next-line-empty-p~
 It replaces the deprecated ~next~ argument to ~org-previous-line-empty-p~.

commit 74d6817ea942b9b20b9a15f47d259ef71ddb83a3
Author: John Kitchin 
Date:   Tue Jul 5 10:29:07 2016 -0400

Update the texinfo for link parameters documentation

diff --git a/doc/org.texi b/doc/org.texi
index e92788f..f962a58 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3711,11 +3711,11 @@ them with @key{up} and @key{down} (or @kbd{M-p/n}).
 valid link prefixes like @samp{http:} or @samp{ftp:}, including the prefixes
 defined through link abbreviations (@pxref{Link abbreviations}).  If you
 press @key{RET} after inserting only the @var{prefix}, Org will offer
-specific completion support for some link types@footnote{This works by
-calling a special function @code{org-PREFIX-complete-link}.}  For
-example, if you type @kbd{file @key{RET}}, file name completion (alternative
-access: @kbd{C-u C-c C-l}, see below) will be offered, and after @kbd{bbdb
-@key{RET}} you can complete contact names.
+specific completion support for some link types@footnote{This works if a
+completion function is defined in the :complete property of a link in
+@var{org-link-parameters}.}  For example, if you type @kbd{file @key{RET}},
+file name completion (alternative access: @kbd{C-u C-c C-l}, see below) will
+be offered, and after @kbd{bbdb @key{RET}} you can complete contact names.
 @orgkey C-u C-c C-l
 @cindex file name completion
 @cindex completion, of file names
@@ -3887,10 +3887,13 @@ can define them in the file 

Re: [O] links-9.0 v3

[John Kitchin]

Thanks. I responded to some below. I didn't respond to all of them. I
will revise the commits accordingly and send a new version.

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> Your version doesn't let you add properties to links with no
>> existing properties, e.g. ("http")
>
> There was a typo (spurious `cdr'), the correct version is
>
>   (defun org-link-set-parameters (type  parameters)
> "Set link TYPE properties to PARAMETERS.
>   PARAMETERS should be :key val pairs."
> (let ((data (assoc type org-link-parameters)))
>   (if data (setcdr data (org-combine-plists (cdr data) parameters))
> (push (cons type parameters) org-link-parameters)
> (org-make-link-regexps)
> (org-element-update-syntax
>
>> and it also didn't work as expected to set properties to nil.

I will give this a try.
>
> Not sure to understand what you mean here. Could you give an example?

If I ran the previous function a few times like this

(org-link-set-parameters "http" :follow nil)

I would get
("http" :follow :follow nil nil nil...)

probably because of the bug. I will let you know if it works.

>> I think I have squashed everything together that makes sense. Let me
>> know if you have further thoughts.
>
> OK. Some comments follow.
>
>> +{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
>> +after {{{samp([)}}} to complete link abbreviations.  You may also
>> +define a function that implements special (e.g., completion) support
>> +for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
>> +should not accept any arguments, and return the full link with
>> +prefix. You can set the link completion function like this:
>
> Mind the spaces after sentences.
I will fix these.

>
> In any case, updating contrib manual is not top priority, since many
> section needs to be updated anyway.
>
>> +[fn:37] This works if a function has been defined in the :complete
>> +property of a link in org-link-parameters.
>
> ~org-link-parameters~
>
>> -(org-add-link-type "id" 'org-id-open)
>> +(org-link-set-parameters "id" :follow 'org-id-open)
>
> Nitpick: #'org-id-open
>
>> -(add-hook 'org-store-link-functions 'org-w3m-store-link)
>> +(org-link-set-parameters "w3m" :store 'org-w3m-store-link)
>
> #'org-w3m-store-link
>
> You get the idea, I will not comment the other occurrences.

Just to make sure I get it, all functions should be sharp quoted like this?

>
>> +   (type (save-match-data
>> +   (if (string-match org-plain-link-re hl)
>> +   (match-string-no-properties 1 hl)
>> + nil)))
>
> Nitpick
>
>   (save-match-data
> (and (string-match org-plain-link-re hl)
>  (match-string-no-properties 1 hl)))
>
>> +   (path (save-match-data
>> +   (if (string-match org-plain-link-re hl)
>> +   (match-string-no-properties 2 hl)
>> + nil)))
>
> Ditto.

ok

>
>> -   ((assoc type org-link-parameters)
>> +   ((and (assoc type org-link-parameters)
>> + (functionp (org-link-get-parameter type :follow)))
>
> I think (functionp ...) is sufficient, no need for the `and' and 
> (assoc type org-link-parameters), which `org-link-get-parameters'
> already takes case of.  So
>
>   ((functionp (org-link-get-parameters type :follow)
>...)
>
>> * lisp/org.el: Replace the variable `org-store-link-functions' with a
>>   function by the same name.
>
> You need to add the name of the function being modified.
>
>> Update org-add-link-type
>> 
>> * lisp/org.el org-add-link-type: deprecated and now calls
>>   `org-link-add'.
>> 
>> Create a new `org-link-add' function for making links.
>
> You probably mean `org-link-set-parameters', since `org-link-add' would
> be but a lesser version of the former.
>
>> +  (org-link-add type :follow follow :export export)
>
> See above.
>
>> +(defun org-store-link-functions ()
>> +  "Returns a list of functions that are called to create and store a link.
>> +The functions in the variable `org-store-link-functions' come
>> +first. These may be user-defined for different contexts. Then
>> +comes the functions defined in the :store property of
>> +org-link-parameters.
>> +
>> +Each function will be called in turn until one returns a non-nil
>> +value. Each function should check if it is responsible for
>> +creating this link (for example by looking at the major mode). If
>> +not, it must exit and return nil. If yes, it should return a
>> +non-nil value after a calling `org-store-link-props' with a list
>> +of properties and values. Special properties are:
>
> Mind the spaces between sentences.
>
> I don't understand why we need to both preserve
> `org-store-link-functions' and use :store property. Wouldn't one
> location be enough?
>

It probably isn't necessary. I will take it out.

>> +:type The link prefix, like \"http\".  This must be given.
>> +:link  

Re: [O] links-9.0 v3

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> Your version doesn't let you add properties to links with no
> existing properties, e.g. ("http")

There was a typo (spurious `cdr'), the correct version is

  (defun org-link-set-parameters (type  parameters)
"Set link TYPE properties to PARAMETERS.
  PARAMETERS should be :key val pairs."
(let ((data (assoc type org-link-parameters)))
  (if data (setcdr data (org-combine-plists (cdr data) parameters))
(push (cons type parameters) org-link-parameters)
(org-make-link-regexps)
(org-element-update-syntax

> and it also didn't work as expected to set properties to nil.

Not sure to understand what you mean here. Could you give an example?

> I think I have squashed everything together that makes sense. Let me
> know if you have further thoughts.

OK. Some comments follow.

> +{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
> +after {{{samp([)}}} to complete link abbreviations.  You may also
> +define a function that implements special (e.g., completion) support
> +for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
> +should not accept any arguments, and return the full link with
> +prefix. You can set the link completion function like this:

Mind the spaces after sentences.

In any case, updating contrib manual is not top priority, since many
section needs to be updated anyway.

> +[fn:37] This works if a function has been defined in the :complete
> +property of a link in org-link-parameters.

~org-link-parameters~

> -(org-add-link-type "id" 'org-id-open)
> +(org-link-set-parameters "id" :follow 'org-id-open)

Nitpick: #'org-id-open

> -(add-hook 'org-store-link-functions 'org-w3m-store-link)
> +(org-link-set-parameters "w3m" :store 'org-w3m-store-link)

#'org-w3m-store-link

You get the idea, I will not comment the other occurrences.

> +(type (save-match-data
> +(if (string-match org-plain-link-re hl)
> +(match-string-no-properties 1 hl)
> +  nil)))

Nitpick

  (save-match-data
(and (string-match org-plain-link-re hl)
 (match-string-no-properties 1 hl)))

> +(path (save-match-data
> +(if (string-match org-plain-link-re hl)
> +(match-string-no-properties 2 hl)
> +  nil)))

Ditto.

> -((assoc type org-link-parameters)
> +((and (assoc type org-link-parameters)
> +  (functionp (org-link-get-parameter type :follow)))

I think (functionp ...) is sufficient, no need for the `and' and 
(assoc type org-link-parameters), which `org-link-get-parameters'
already takes case of.  So

  ((functionp (org-link-get-parameters type :follow)
   ...)

> * lisp/org.el: Replace the variable `org-store-link-functions' with a
>   function by the same name.

You need to add the name of the function being modified.

> Update org-add-link-type
> 
> * lisp/org.el org-add-link-type: deprecated and now calls
>   `org-link-add'.
> 
> Create a new `org-link-add' function for making links.

You probably mean `org-link-set-parameters', since `org-link-add' would
be but a lesser version of the former.

> +  (org-link-add type :follow follow :export export)

See above.

> +(defun org-store-link-functions ()
> +  "Returns a list of functions that are called to create and store a link.
> +The functions in the variable `org-store-link-functions' come
> +first. These may be user-defined for different contexts. Then
> +comes the functions defined in the :store property of
> +org-link-parameters.
> +
> +Each function will be called in turn until one returns a non-nil
> +value. Each function should check if it is responsible for
> +creating this link (for example by looking at the major mode). If
> +not, it must exit and return nil. If yes, it should return a
> +non-nil value after a calling `org-store-link-props' with a list
> +of properties and values. Special properties are:

Mind the spaces between sentences.

I don't understand why we need to both preserve
`org-store-link-functions' and use :store property. Wouldn't one
location be enough?

> +:type The link prefix, like \"http\".  This must be given.
> +:link The link, like \"http://www.astro.uva.nl/~dominik\;.
> +  This is obligatory as well.
> +:description  Optional default description for the second pair
> +  of brackets in an Org-mode link.  The user can still change
> +  this when inserting this link into an Org-mode buffer.

Org-mode -> Org mode

> +In addition to these, any additional properties can be specified
> +and then used in capture templates."
> +  (append
> +   org-store-link-functions
> +   (cl-loop for link in org-link-parameters
> + with store-func
> + do (setq store-func (org-link-get-parameter (car link) :store))
> + if store-func
> + collect store-func)))

[O] links-9.0 v3

[John Kitchin]

I found some difficulties with the org-link-set-parameters you suggested
Nick. Your version doesn't let you add properties to links with no
existing properties, e.g. ("http") and it also didn't work as expected
to set properties to nil. The current function is one you didn't like
earlier with setf and cl-getf, but it does exactly what it should as far
as I can tell.

I also modified the org-open-at-point function so the http type of
links with no :follow function work with it. These diffs pass all the
tests for me except the two that don't pass on master either.

I think I have squashed everything together that makes sense. Let me
know if you have further thoughts.


commit 92db211ca9f95d5624b83615c83c62d8c703ca00
Author: John Kitchin 
Date:   Tue Jul 5 10:38:42 2016 -0400

Update the contrib manual

diff --git a/contrib/orgmanual.org b/contrib/orgmanual.org
index e48ae97..4346083 100644
--- a/contrib/orgmanual.org
+++ b/contrib/orgmanual.org
@@ -3300,12 +3300,16 @@ can define them in the file with
   ,#+LINK: googlehttp://www.google.com/search?q=%s
 #+end_src
 
-{{{noindent}}} In-buffer completion (see [[Completion]]) can be used after
-{{{samp([)}}} to complete link abbreviations.  You may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+{{{noindent}}} In-buffer completion (see [[Completion]]) can be used
+after {{{samp([)}}} to complete link abbreviations.  You may also
+define a function that implements special (e.g., completion) support
+for inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function
+should not accept any arguments, and return the full link with
+prefix. You can set the link completion function like this:
+
+#+BEGIN_SRC emacs-lisp
+(org-link-set-parameter "type" :complete 'some-completion-function)
+#+END_SRC
 
 ** Search options
:PROPERTIES:
@@ -16998,10 +17002,9 @@ description when the link is later inserted into an 
Org buffer with
 {{{kbd(C-c C-l)}}}.
 
 When it makes sense for your new link type, you may also define a
-function ~org-PREFIX-complete-link~ that implements special (e.g.,
-completion) support for inserting such a link with {{{kbd(C-c C-l)}}}.
-Such a function should not accept any arguments, and return the full
-link with prefix.
+function that implements special (e.g., completion) support for
+inserting such a link with {{{kbd(C-c C-l)}}}.  Such a function should
+not accept any arguments, and return the full link with prefix.
 
 ** Context-sensitive commands
:PROPERTIES:
@@ -19181,8 +19184,8 @@ from the list of stored links.  To keep it in the list 
later use, use a
 triple {{{kbd(C-u)}}} prefix argument to {{{kbd(C-c C-l)}}}, or
 configure the option ~org-keep-stored-link-after-insertion~.
 
-[fn:37] This works by calling a special function
-~org-PREFIX-complete-link~.
+[fn:37] This works if a function has been defined in the :complete
+property of a link in org-link-parameters.
 
 [fn:38] See the variable ~org-display-internal-link-with-indirect-buffer~.
 

commit 895d48e4d11abdd5994c0ac2d0074e0e7efd7533
Author: John Kitchin 
Date:   Tue Jul 5 10:31:30 2016 -0400

Update NEWS with link announcement

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9909910..6ff7442 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -353,6 +353,8 @@ first footnote.
 *** The ~org-block~ face is inherited by ~src-blocks~
 This works also when =org-src-fontify-natively= is non-nil.  It is also
 possible to specify per-languages faces.  See the manual for details.
+*** Links are now customizable
+Links can now have custom colors, tooltips, keymaps, display behavior, etc... 
Links are now centralized in ~org-link-parameters~.
 ** New functions
 *** ~org-next-line-empty-p~
 It replaces the deprecated ~next~ argument to ~org-previous-line-empty-p~.

commit c9f14fa9541139c5700ef0e7a522c837411fafc7
Author: John Kitchin 
Date:   Tue Jul 5 10:29:07 2016 -0400

Update the texinfo for link parameters documentation

diff --git a/doc/org.texi b/doc/org.texi
index e92788f..aa552fc 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3711,11 +3711,11 @@ them with @key{up} and @key{down} (or @kbd{M-p/n}).
 valid link prefixes like @samp{http:} or @samp{ftp:}, including the prefixes
 defined through link abbreviations (@pxref{Link abbreviations}).  If you
 press @key{RET} after inserting only the @var{prefix}, Org will offer
-specific completion support for some link types@footnote{This works by
-calling a special function @code{org-PREFIX-complete-link}.}  For
-example, if you type @kbd{file @key{RET}}, file name completion (alternative
-access: @kbd{C-u C-c C-l}, see below) will be offered, and after @kbd{bbdb
-@key{RET}} you can complete contact names.
+specific completion support for some link 

Re: [O] links in headlines and org-bbdb-anniversaries

[Kyle Meyer]

Hello,

George McNinch  writes:

> Hi--
>
> I use org via ELPA. This week, the packages
>
>  org-20160118
>  org-plus-contrib-20160118
>
> were replaced by
>
>  org-20160125
>  org-plus-contrib-20160125
>
> After update, org began complaining about links in the headlines
> which appear in my *Agenda*.
>
> More precisely, this was reported:
>
>> org-agenda-finalize: Wrong type argument: listp, org-link

I believe this is the same issue as
http://thread.gmane.org/gmane.emacs.orgmode/104539.

It's been fixed and will be available in the next ELPA build.

-- 
Kyle

Re: [O] links in headlines and org-bbdb-anniversaries

[George McNinch]

Kyle> I believe this is the same issue as
Kyle> http://thread.gmane.org/gmane.emacs.orgmode/104539.

Kyle> It's been fixed and will be available in the next ELPA build.

Whoops; thanks -- I missed that.

-gm


-- 
   =---=   George McNinch 
   =---=   http://gmcninch.math.tufts.edu 

[O] links in headlines and org-bbdb-anniversaries

[George McNinch]

Hi--

I use org via ELPA. This week, the packages

 org-20160118
 org-plus-contrib-20160118

were replaced by

 org-20160125
 org-plus-contrib-20160125

After update, org began complaining about links in the headlines
which appear in my *Agenda*.

More precisely, this was reported:

   > org-agenda-finalize: Wrong type argument: listp, org-link

So, I removed links from my headlines.

But: I still get the error, I believe because I have

%%(org-bbdb-anniversaries)

in my agenda. The result of org-bbdb-anniversaries seems to at least act
like headlines from the point-of-view of the agenda, and those headlines
contain [bbdb:...][...] links.

All the best,
gm

-- 
   |∈|∋|   George McNinch 
   |∈|∋|   http://gmcninch.math.tufts.edu 

[O] Links in headings are broken

[Titus von der Malsburg]

I just updated org-mode from Elpa and since then links in headings are
not anymore interpreted as links.  Example:

* [[http://www.google.com][Google]]

I’d expect to see

* Google

with “Google” being clickable but instead I see the complete code for
the link.  Links in normal text work as usual.

Tested with Emacs -Q on a recent development version of Emacs.

  Titus




signature.asc
Description: PGP signature

Re: [O] Links in headings are broken

[Bruno Bigras]

I think I have the same problem. Also some "TODO" keywords are now
highlighted in some headings but it could be related.

In the "*messages*" buffer I have:
font-lock-fontify-keywords-region: Wrong type argument: listp,
org-level-1Error during redisplay: (jit-lock-function 240) signaled
(wrong-type-argument listp org-level-1)
Error during redisplay: (jit-lock-function 1906) signaled
(wrong-type-argument listp org-level-1)
Error during redisplay: (jit-lock-function 8102) signaled
(wrong-type-argument listp org-level-1)
Error during redisplay: (jit-lock-function 9663) signaled
(wrong-type-argument listp org-level-1)


Le mar. 26 janv. 2016 à 14:20, Titus von der Malsburg 
a écrit :

>
>
> I just updated org-mode from Elpa and since then links in headings are
> not anymore interpreted as links.  Example:
>
> * [[http://www.google.com][Google]]
>
> I’d expect to see
>
> * Google
>
> with “Google” being clickable but instead I see the complete code for
> the link.  Links in normal text work as usual.
>
> Tested with Emacs -Q on a recent development version of Emacs.
>
>   Titus
>
>
> --
Bruno

Re: [O] Links in headings are broken

[Titus von der Malsburg]

On 2016-01-26 Tue 11:35, Bruno Bigras wrote:
> I think I have the same problem. Also some "TODO" keywords are now
> highlighted in some headings but it could be related.

I can confirm the error messages.  Also, I think Bruno means that the
TODO keywords are *not* highlighted.  This also affects other keywords
not just TODO and I can’t really see what is triggering it.  I have one
very large org file with hundreds of TODO items and about 10% of the
TODO/DONE/… keywords are not highlighted.  The non-highlighted keywords
usually occur in streaks (in consecutive headings).

  Titus

>
> In the "*messages*" buffer I have:
> font-lock-fontify-keywords-region: Wrong type argument: listp,
> org-level-1Error during redisplay: (jit-lock-function 240) signaled
> (wrong-type-argument listp org-level-1)
> Error during redisplay: (jit-lock-function 1906) signaled
> (wrong-type-argument listp org-level-1)
> Error during redisplay: (jit-lock-function 8102) signaled
> (wrong-type-argument listp org-level-1)
> Error during redisplay: (jit-lock-function 9663) signaled
> (wrong-type-argument listp org-level-1)
>
>
> Le mar. 26 janv. 2016 à 14:20, Titus von der Malsburg 
> a écrit :
>
>>
>>
>> I just updated org-mode from Elpa and since then links in headings are
>> not anymore interpreted as links.  Example:
>>
>> * [[http://www.google.com][Google]]
>>
>> I’d expect to see
>>
>> * Google
>>
>> with “Google” being clickable but instead I see the complete code for
>> the link.  Links in normal text work as usual.
>>
>> Tested with Emacs -Q on a recent development version of Emacs.
>>
>>   Titus
>>
>>
>> --
> Bruno



signature.asc
Description: PGP signature

Re: [O] Links in headings are broken

[Bruno Bigras]

2016-01-26 14:58 GMT-05:00 Titus von der Malsburg :
> I think Bruno means that the TODO keywords are *not* highlighted.

You're right. Sorry for the confusion.

Re: [O] Links in headings are broken

[Nicolas Goaziou]

Hello,

Bruno Bigras  writes:

> 2016-01-26 14:58 GMT-05:00 Titus von der Malsburg :
>> I think Bruno means that the TODO keywords are *not* highlighted.
>
> You're right. Sorry for the confusion.

This was fixed yesterday.

Regards,

-- 
Nicolas Goaziou

Re: [O] Links in comments

[Eric S Fraga]

On Wednesday, 28 Oct 2015 at 07:07, Kaushal Modi wrote:
> Hi John, Eric,
>
> Thanks for the replies.
>
> I will try out the highlight-regexp trick today.
>
> The point I was trying to make was not that we should highlight links even
> in comments (though that was my suggested alternative). The main point I
> wanted to make was that links should not get hidden in comments.

Ah, sorry, I misunderstood.  I agree with you, again from a semantic
point of view of what a comment (to me) means.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Links in comments

[Kaushal Modi]

Hi John, Eric,

Thanks for the replies.

I will try out the highlight-regexp trick today.

The point I was trying to make was not that we should highlight links even
in comments (though that was my suggested alternative). The main point I
wanted to make was that links should not get hidden in comments.

If highlighting links in comments is not suggested, then at least we should
make them visible as,

# some [[link][desc]]

Instead of

# some desc

The use case is where I would have some org-mode text with links
temporarily commented out. But in the commented state, I would not know if
that text hid any links because the links don't show expanded in the
commented text. And also they don't have a different face.

I will update later on what I see on using highlight-regexp. I think that
will work for me too.

Re: [O] Links in comments

[Samuel Wales]

(highlight-regexp org-ts-regexp3 'org-date)

Re: [O] Links in comments

[Samuel Wales]

On 10/28/15, John Kitchin  wrote:
> Your mileage may vary, but this seems to show links in comments for me:
>
> #+BEGIN_EXAMPLE
> (highlight-regexp org-any-link-re 'org-link)
> #+END_EXAMPLE

nice workaround!  thanks!

it's a matter of perspective.  comments mean two separate things:

  1] "commenting out"
  2] "note to self"

note that org-mouse does [and should if and only if fontified] allow
clicks on commented links, following the "note to self" principle.

Re: [O] Links in comments

[John Kitchin]

Your mileage may vary, but this seems to show links in comments for me:

#+BEGIN_EXAMPLE
(highlight-regexp org-any-link-re 'org-link)
#+END_EXAMPLE


Eric S Fraga writes:

> On Monday, 26 Oct 2015 at 14:13, Kaushal Modi wrote:
>> Hi all,
>>
>> I am sending this out again in the event someone knowing a solution to it
>> can comment.
>
> I don't know a solution.  If I do C-u C-x = with the cursor on the link
> in a comment line, there is only one face shown.  Semantically, the line
> is a comment and the whole point of comments is that they are not parsed
> for any further meaning.  Representing the line, therefore, using the
> comment face throughout makes sense.
>
> Whether it's what *you* want or not is another issue, of course ;-)
>
> I suggest changing your usage?  If you want links to be visible, they
> should be in the main text?  Even within a COMMENT section say?

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

Re: [O] Links in comments

[Eric S Fraga]

On Monday, 26 Oct 2015 at 14:13, Kaushal Modi wrote:
> Hi all,
>
> I am sending this out again in the event someone knowing a solution to it
> can comment.

I don't know a solution.  If I do C-u C-x = with the cursor on the link
in a comment line, there is only one face shown.  Semantically, the line
is a comment and the whole point of comments is that they are not parsed
for any further meaning.  Representing the line, therefore, using the
comment face throughout makes sense.

Whether it's what *you* want or not is another issue, of course ;-)

I suggest changing your usage?  If you want links to be visible, they
should be in the main text?  Even within a COMMENT section say?
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Links in comments

[Kaushal Modi]

Hi all,

I am sending this out again in the event someone knowing a solution to it
can comment.


--
Kaushal Modi

On Mon, Oct 19, 2015 at 6:54 PM, Kaushal Modi 
wrote:

> Hi,
>
> This question has come up a few times on emacs.stackexchange so I was
> curious if the more experienced org-mode users had a solution to this.. or
> if a fix is needed to resolve this issue.
>
> Referenced emacs.stackexchange questions:
>
> - http://emacs.stackexchange.com/q/17505/115
> - http://emacs.stackexchange.com/q/9413/115
>
>
> The issue if that if there is a link in an org-mode commented line like
> below:
>
> * Links in comments
> #+BEGIN_EXAMPLE
> # This is a [[http://orgmode.org][link]] in a comment.
> #+END_EXAMPLE
> # This is a [[http://orgmode.org][link]] in a comment.
>
> the link gets completely camouflaged as seen below.
>
> [image: Inline image 3]
>
> The only way I know that that's a link is if I toggle the visible-mode or
> hover over that link with mouse (as below).
>
> [image: Inline image 1]
>
> Solutions??
> - Different face for such links within comments? Or let the link face
> supersede comment face?
> - Option to not collapse links within comments?
>
> What do you guys think?
>
>
> --
> Kaushal Modi
>

[O] Links in comments

[Kaushal Modi]

Hi,

This question has come up a few times on emacs.stackexchange so I was
curious if the more experienced org-mode users had a solution to this.. or
if a fix is needed to resolve this issue.

Referenced emacs.stackexchange questions:

- http://emacs.stackexchange.com/q/17505/115
- http://emacs.stackexchange.com/q/9413/115


The issue if that if there is a link in an org-mode commented line like
below:

* Links in comments
#+BEGIN_EXAMPLE
# This is a [[http://orgmode.org][link]] in a comment.
#+END_EXAMPLE
# This is a [[http://orgmode.org][link]] in a comment.

the link gets completely camouflaged as seen below.

[image: Inline image 3]

The only way I know that that's a link is if I toggle the visible-mode or
hover over that link with mouse (as below).

[image: Inline image 1]

Solutions??
- Different face for such links within comments? Or let the link face
supersede comment face?
- Option to not collapse links within comments?

What do you guys think?


--
Kaushal Modi

Re: [O] links with italic descriptions are broken in maint

[Nicolas Goaziou]

Samuel Wales  writes:

> please set RET to follow links and try RET.

OK. This is clearer now. Fixed. Thank you.


Regards,

Re: [O] links with italic descriptions are broken in maint

[Samuel Wales]

please set RET to follow links and try RET.

[O] links with italic descriptions are broken in maint

[Samuel Wales]

* NEXT /links with italics break/
SCHEDULED: <2015-10-10 Sat>
:PROPERTIES:
:ID:   6fb16bf3-1e92-4ec0-b35a-0cfb2b19cd21
:END:

[[id:6fb16bf3-1e92-4ec0-b35a-0cfb2b19cd21][/links with italics break/]]
[[id:6fb16bf3-1e92-4ec0-b35a-0cfb2b19cd21][links with italics break]]


-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

Ramsay's disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: [O] links with italic descriptions are broken in maint

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> * NEXT /links with italics break/
> SCHEDULED: <2015-10-10 Sat>
> :PROPERTIES:
> :ID:   6fb16bf3-1e92-4ec0-b35a-0cfb2b19cd21
> :END:
>
> [[id:6fb16bf3-1e92-4ec0-b35a-0cfb2b19cd21][/links with italics break/]]
> [[id:6fb16bf3-1e92-4ec0-b35a-0cfb2b19cd21][links with italics break]]

FWIW, I have no problem exporting, e.g.,

  [[http://orgmode.org][/links with italics/]]


Regards,

-- 
Nicolas Goaziou

Re: [O] Links to Info manuals in exported HTML/LaTeX

[Suvayu Ali]

On Thu, Aug 27, 2015 at 10:19:40AM +0200, Marcin Borkowski wrote:
 Hi all,
 
 it seems that links to Info manuals are broken in HTML and LaTeX export
 (and possibly in other backends, too).
 
 Would it make sense to make them work, i.e., link to the official web
 versions, at least for standard Info manuals, like Emacs manual, Elisp
 reference or Org manual?

You could probably use filters (org-export-filter-link-functions) to
point them where you want them.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Links to Info manuals in exported HTML/LaTeX

[Richard Y. Kim]

Marcin Borkowski mb...@mbork.pl writes:

 Hi all,

 it seems that links to Info manuals are broken in HTML and LaTeX export
 (and possibly in other backends, too).

 Would it make sense to make them work, i.e., link to the official web
 versions, at least for standard Info manuals, like Emacs manual, Elisp
 reference or Org manual?

It is not broken for my use case.  I like the fact that 

[[info:emacs#Top][Emacs Manual]]

is turned into

a href=emacs.html#TopEmacs Manual/a

because I generated emacs.html, elisp.html, org.html, etc. all in
my ~/public_html/ or sub-directories.  Hence 
a href=emacs.html#TopEmacs Manual/a
works fine for my use case.  It is a lot faster to access GNU manuals
when they are all on local host.

Should the current behavior be the default?  Perhaps not.  I believe
makeinfo and/or texi2html generates html links pointing to the official
pages at gnu.org.  This could be the default behavior, but I hope not
the *only* behavior.  If current export code is to be changed, I would
like to see user selectable option so that I can choose to use the
current behavior.

[O] Links to Info manuals in exported HTML/LaTeX

[Marcin Borkowski]

Hi all,

it seems that links to Info manuals are broken in HTML and LaTeX export
(and possibly in other backends, too).

Would it make sense to make them work, i.e., link to the official web
versions, at least for standard Info manuals, like Emacs manual, Elisp
reference or Org manual?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] Links

[Suvayu Ali]

On Wed, Jun 17, 2015 at 11:47:38AM +0200, Nicolas Goaziou wrote:

 [... description of the issues trimmed ...]

  Although, you still have to handle the ambiguous case for existing Org
  files.  Unless this double maintenance is cumbersome, I would vote for
  introducing such a scheme.
 
 The double maintenance is not possible. Either we take into
 consideration the prefix or the heuristic rule above, and some links are
 going to break, or we allow to bypass it and it doesn't improve the
 situation.

This is tricky indeed.  I guess the heuristic is the safest bet when it
comes to compatibility.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Links, exporter

[Fabrice Popineau]

2015-06-17 12:42 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr:

 Hello,

 Fabrice Popineau fabrice.popin...@gmail.com writes:

  If I try to export the Second Blog entry subtree by C-C C-e C-s C-b h
 H,
  I get a user-error because the exporter can't resolve the link which
 points
  outside of the exported subtree.
 
  Is this expected?

 Yes, unresolved links/footnotes/whatever throw errors instead of leaving
 broken links.


Ok. I was surprised because months ago, it went unnotified.
It makes sense, even if it is pretty restrictive.
Errors could have been postponed to html/latex processing but that
wouldn't help either to fix them.

Thanks. Best regards,

Re: [O] Links, exporter

[Nicolas Goaziou]

Hello,

Fabrice Popineau fabrice.popin...@gmail.com writes:

 If I try to export the Second Blog entry subtree by C-C C-e C-s C-b h H,
 I get a user-error because the exporter can't resolve the link which points
 outside of the exported subtree.

 Is this expected?

Yes, unresolved links/footnotes/whatever throw errors instead of leaving
broken links.

 Maybe that is a bad idea, but I was thinking that the link could be
 resolved as if we were exporting the whole file rather than error
 it.

It could work for HTML export but it cannot be generalized (e.g., you
cannot have a dangling \ref{something} without a corresponding
\label{...} in LaTeX). So, it is consistent.


Regards,

-- 
Nicolas Goaziou

[O] Links, exporter

[Fabrice Popineau]

Hi,

I have another problem/question with links related to the exporter.

I lost track of what was the behavior months ago.

Assume I have something like this :


* BAR
:PROPERTIES:
:PAGE: bar.html
:END:

** First link   :first:
:PROPERTIES:
:CUSTOM_ID: First%20link
:END:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
dolor. Nullam tristique diam non turpis. Cras placerat accumsan
nulla. Nullam rutrum. Nam vestibulum accumsan nisl.

** Second link

*** Third level

- [[#First%20link][First link]] foo bar
- [[file:sample.org][sample.org]]
- [[http://www.google.com][Google]]


* BLOG

** DONE BLOG Entry   :blog:foo:
   CLOSED: [2015-06-17 mer. 10:15]

 Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
 tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
 mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
 dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
 dolor. Nullam tristique diam non turpis. Cras placerat accumsan
 nulla. Nullam rutrum. Nam vestibulum accumsan nisl.


** DONE Second Blog entry   :blog:bar:
   CLOSED: [2015-06-17 mer. 11:17]

 [[#First%20link][First link again]]

 See if this will work.

If I try to export the Second Blog entry subtree by C-C C-e C-s C-b h H,
I get a user-error because the exporter can't resolve the link which points
outside of the exported subtree.

Is this expected?
Maybe that is a bad idea, but I was thinking that the link could be
resolved as if we were exporting the whole file rather than error it.

Thanks for enlighting me.

Fabrice

Re: [O] Links

[Nicolas Goaziou]

Hello,

Suvayu Ali fatkasuvayu+li...@gmail.com writes:

 Would it make sense to promote these kind of encoded links to almost
 their own sub-types?  I would guess, almost no one enters these encoded
 links by hand.  It's either via copy paste in the prompt from
 org-insert-link, or by entering [[encoded-link][description]] by hand.
 I think it is a reasonable inconvenience to ask the user to prefix it
 with something like uri:.  I mostly see advantages for a minor
 inconvenience.

I don't think we should go as far as changing link syntax for this.

Actually, the problem lies in internal links, since external ones are
expected to be url-encoded when necessary.

Internal links only require url-encoding when they contain square
brackets. So, we can make a guess: if a string either doesn't contain
%5B or %5D, or contains any character in `org-link-escape-chars'
(with the exception of the percent sign), it cannot be encoded.

Otherwise, we can assume it is encoded. In this case, there are false
positives, but those are sufficiently rare (i.e., an internal link with
either %5B or %5D and no space in it) this should not be a problem
in practice.

There is an important drawback however, as in the prefix proposal:
currently encoded internal links (e.g. Headline%201) will break.

 Although, you still have to handle the ambiguous case for existing Org
 files.  Unless this double maintenance is cumbersome, I would vote for
 introducing such a scheme.

The double maintenance is not possible. Either we take into
consideration the prefix or the heuristic rule above, and some links are
going to break, or we allow to bypass it and it doesn't improve the
situation.


Regards,

-- 
Nicolas Goaziou

Re: [O] Links

[Suvayu Ali]

Hi Nicolas, Fabrice,

On Tue, Jun 16, 2015 at 11:30:06PM +0200, Nicolas Goaziou wrote:
 Fabrice Popineau fabrice.popin...@gmail.com writes:
 
  Ideally, url encoded links should have been prefixed with some kind of uri
  syntax.
  This way, you could know what to decode and what not.
 
 The encoded link could be copied from somewhere else. Also, there are
 numerous links in the wild without this prefix.

Would it make sense to promote these kind of encoded links to almost
their own sub-types?  I would guess, almost no one enters these encoded
links by hand.  It's either via copy paste in the prompt from
org-insert-link, or by entering [[encoded-link][description]] by hand.
I think it is a reasonable inconvenience to ask the user to prefix it
with something like uri:.  I mostly see advantages for a minor
inconvenience.  

Although, you still have to handle the ambiguous case for existing Org
files.  Unless this double maintenance is cumbersome, I would vote for
introducing such a scheme.

What do others think?

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Links

[Nicolas Goaziou]

Hello,

Fabrice Popineau fabrice.popin...@gmail.com writes:

 Assume the following file :

[...]

 ** First link

[...]

 ** Second link
 [2015-06-16 mar. 13:58]

 - [[First%20link][First link]]

[...]

 The exporter fails to resolve the (fuzzy) link First%20link.
 However, if I click on the link, I jump to the right heading.

 Am I missing something or should this be made consistent ?

You are not missing something, but making it consistent is not as
trivial as it sounds.

The problem is that, AFAIK, we cannot tell if a given string is
url-encoded or not. Also, url-encoding is not idempotent.

So, export process doesn't url-decode links, and cannot handle the link
above. OTOH, `org-open-at-point' assumes links are url-encoded (and they
are if you stored them with `org-store-link') so it url-decodes the link
above and is able to follow it.

I think it would be a mistake to expect all links to be url-encoded as
it is a pain when you enter most of your internal links manually.
However, forbidding url-encoding for internal links is also a mistake
because some of them cannot be expressed otherwise (e.g., headlines
containing square brackets). The current situation is also problematic,
of course. Well.

At this point, it seems that all is left are cheesy approaches. E.g,
when a path matches %[A-Za-z0-9]\\{2\\}, decode it during export. This
leaves pathological cases (e.g., when you really meant, for some very
good reason, to have a headline called * %25), though. That's not
great either.

WDYT?

Regards,

-- 
Nicolas Goaziou

[O] Links

[Fabrice Popineau]

Hi,

I think I need some refresh on what's valid and what is not.

Assume the following file :

#+TITLE: Foo
#+DATE: 2014-11-19 01:10:58

* FOO
[2015-06-16 mar. 13:58]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
dolor. Nullam tristique diam non turpis. Cras placerat accumsan
nulla. Nullam rutrum. Nam vestibulum accumsan nisl.

* BAR
[2015-06-16 mar. 13:58]
** First link
[2015-06-16 mar. 13:58]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
dolor. Nullam tristique diam non turpis. Cras placerat accumsan
nulla. Nullam rutrum. Nam vestibulum accumsan nisl.

** Second link
[2015-06-16 mar. 13:58]

- [[First%20link][First link]]
- [[file:sample.org][sample.org]]
- [[http://www.google.com][Google]]

The exporter fails to resolve the (fuzzy) link First%20link.
However, if I click on the link, I jump to the right heading.

Am I missing something or should this be made consistent ?

Fabrice

Re: [O] Links

[Fabrice Popineau]

2015-06-16 14:50 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr:

 Hello,


 So, export process doesn't url-decode links, and cannot handle the link
 above.


This is what I was missing :-)


 At this point, it seems that all is left are cheesy approaches. E.g,
 when a path matches %[A-Za-z0-9]\\{2\\}, decode it during export. This
 leaves pathological cases (e.g., when you really meant, for some very
 good reason, to have a headline called * %25), though. That's not
 great either.

 WDYT?


I don't know what is realistic. I see the tradeoffs are tight.

Ideally, url encoded links should have been prefixed with some kind of uri
syntax.
This way, you could know what to decode and what not.

Now, I guess the heuristic you propose would be fine in most cases.
I don't see that people will put a lot of percentages in their links.

Thanks for the explanations !

Fabrice


 Regards,

 --
 Nicolas Goaziou

Re: [O] Links

[Nicolas Goaziou]

Fabrice Popineau fabrice.popin...@gmail.com writes:

 Ideally, url encoded links should have been prefixed with some kind of uri
 syntax.
 This way, you could know what to decode and what not.

The encoded link could be copied from somewhere else. Also, there are
numerous links in the wild without this prefix.

 Now, I guess the heuristic you propose would be fine in most cases.
 I don't see that people will put a lot of percentages in their links.

I pushed something along these lines in master. It should solve your
initial issue.

Thank you.

Regards,

Re: [O] Links in #+caption: lines

[Nicolas Goaziou]

Rasmus ras...@gmx.us writes:

 Would it be possible to specify inheritance priority?  So that e.g. link
 would retain the blue coloring?

One solution would be to split fontification of raw keywords and blocks
OTOH and blocks that can contain Org data OTOH, as suggested by Kaushal
(http://permalink.gmane.org/gmane.emacs.orgmode/97530, Cc'ed).

Link fontification would happen after the latter, but before the former.

Anyway, after 8.3 release (or maybe 8.4 depending on the bugs
encountered), we'll have to drop regexp fontification for parser
fontification so this problem will simply disappear.

Regards,

Re: [O] Links in #+caption: lines

[Thomas S. Dye]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Rasmus ras...@gmx.us writes:

 Would it be possible to specify inheritance priority?  So that e.g. link
 would retain the blue coloring?

 One solution would be to split fontification of raw keywords and blocks
 OTOH and blocks that can contain Org data OTOH, as suggested by Kaushal
 (http://permalink.gmane.org/gmane.emacs.orgmode/97530, Cc'ed).

 Link fontification would happen after the latter, but before the former.

 Anyway, after 8.3 release (or maybe 8.4 depending on the bugs
 encountered), we'll have to drop regexp fontification for parser
 fontification so this problem will simply disappear.

Sounds good to me.  Full speed ahead on 8.3/8.4 then.

All the best,
Tom

-- 
T.S. Dye  Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] Links in #+caption: lines

[Thomas S. Dye]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Rasmus ras...@gmx.us writes:

 Try the attached patch.

 I have done 20 second of testing (I'm traveling) so there may be adverse
 effects.  But it looked OK.

 With this patch, you remove fontification from caption contents, which
 is not desirable. Caption is an affiliated keyword and should be marked
 as such.

Is it possible to have descriptive links in captions?

All the best,
Tom

-- 
T.S. Dye  Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] Links in #+caption: lines

[Nicolas Goaziou]

Hello,

Rasmus ras...@gmx.us writes:

 Try the attached patch.

 I have done 20 second of testing (I'm traveling) so there may be adverse
 effects.  But it looked OK.

With this patch, you remove fontification from caption contents, which
is not desirable. Caption is an affiliated keyword and should be marked
as such.


Regards,

-- 
Nicolas Goaziou

Re: [O] Links in #+caption: lines

[Rasmus]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Rasmus ras...@gmx.us writes:

 Try the attached patch.

 I have done 20 second of testing (I'm traveling) so there may be adverse
 effects.  But it looked OK.

 With this patch, you remove fontification from caption contents, which
 is not desirable. Caption is an affiliated keyword and should be marked
 as such.

I was not proposing merging it.  Perhaps it can be changed to an advice or
something.

Would it be possible to specify inheritance priority?  So that e.g. link
would retain the blue coloring?

Rasmus

-- 
Vote for Dick Taid in an election near you!

Re: [O] Links in #+caption: lines

[Rasmus]

Hi,

t...@tsdye.com (Thomas S. Dye) writes:

 In the patch I guess this is the passage you disagree with:

 +  ((equal dc1 +caption:)
 +   (org-remove-flyspell-overlays-in (match-end 2) (match-end 0))
 +   (remove-text-properties (match-beginning 0) (match-end 0)
 +   '(display t invisible t intangible t))
 +   (add-text-properties (match-beginning 1) (match-end 3)
 +'(font-lock-fontified t face org-meta-line))
 +   (add-text-properties (match-beginning 6) (+ (match-end 6) 1)
 +'(font-lock-fontified t face org-block)))

 Perhaps it is possible to let normal fontification rule in region six
 above?

 How would I change this so descriptive links are shown in #+caption:
 lines?

Try the attached patch.

I have done 20 second of testing (I'm traveling) so there may be adverse
effects.  But it looked OK.

Have a nice weekend.

—Rasmus

-- 
With monopolies the cake is a lie!
From bdfbda33ee01200f52393884c51e8fc865f8ec0c Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Fri, 5 Jun 2015 07:38:13 +0200
Subject: [PATCH] org.el: Alter caption label formatting

* org.el (org-fontify-meta-lines-and-blocks-1): Caption labels
  retain normally formatted.
---
 lisp/org.el | 4 
 1 file changed, 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 62684e9..81d1022 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5951,12 +5951,8 @@ by a #.
 	   '(font-lock-fontified t face org-document-info
 	   ((equal dc1 +caption:)
 	(org-remove-flyspell-overlays-in (match-end 2) (match-end 0))
-	(remove-text-properties (match-beginning 0) (match-end 0)
-'(display t invisible t intangible t))
 	(add-text-properties (match-beginning 1) (match-end 3)
  '(font-lock-fontified t face org-meta-line))
-	(add-text-properties (match-beginning 6) (+ (match-end 6) 1)
- '(font-lock-fontified t face org-block))
 	t)
 	   ((member dc3 '(  ))
 	(org-remove-flyspell-overlays-in beg (match-end 0))
-- 
2.4.2

Re: [O] Links in #+caption: lines

[Thomas S. Dye]

Rasmus ras...@gmx.us writes:

 In the patch I guess this is the passage you disagree with:

 +  ((equal dc1 +caption:)
 +   (org-remove-flyspell-overlays-in (match-end 2) (match-end 0))
 +   (remove-text-properties (match-beginning 0) (match-end 0)
 +   '(display t invisible t intangible t))
 +   (add-text-properties (match-beginning 1) (match-end 3)
 +'(font-lock-fontified t face org-meta-line))
 +   (add-text-properties (match-beginning 6) (+ (match-end 6) 1)
 +'(font-lock-fontified t face org-block)))

 Perhaps it is possible to let normal fontification rule in region six
 above?

How would I change this so descriptive links are shown in #+caption:
lines?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Links in #+caption: lines

[Rasmus]

Hi,

t...@tsdye.com (Thomas S. Dye) writes:

 I don't know if it is an effect of 37d2a2d.

I just tested it against 50a0e712cceeef02c0d6a7c41b619b308ea1b15c.
37d2a2d seems critical here.

 I'm also seeing a different background for captions, similar to the
 background the emacs 24 starter kit gives me for #+begin_src and
 #+end_src lines.

On my computer with angry fruit colors, captions are formatted as

  #+caption: caption text
AFC color RedGray
Face  org-meta-line  org-block 

I don't know starter kit.  But the Leuven theme changes background colors
for various parts of Org like this:

  
https://github.com/fniessen/emacs-leuven-theme/blob/master/images/agenda-and-task-list.png

Is that your theme?

 I use links for citations, which frequently appear in captions when I
 specify the source of data, etc.  The paper I'm working on now looks a
 bit ungainly in the Org mode buffer due to the literal links in captions
 and the weird backgrounds.

For the latter try something like: (set-face-background 'org-block nil)

 If it is necessary to choose between literal links in macros or
 descriptive links in captions, perhaps there could be a switch for users
 like you and me who use one but not the other?

In the patch I guess this is the passage you disagree with:

+  ((equal dc1 +caption:)
+   (org-remove-flyspell-overlays-in (match-end 2) (match-end 0))
+   (remove-text-properties (match-beginning 0) (match-end 0)
+   '(display t invisible t intangible t))
+   (add-text-properties (match-beginning 1) (match-end 3)
+'(font-lock-fontified t face org-meta-line))
+   (add-text-properties (match-beginning 6) (+ (match-end 6) 1)
+'(font-lock-fontified t face org-block)))

Perhaps it is possible to let normal fontification rule in region six
above?

IMO hidden link (== no color highlight and not literal) is no good.

Rasmus

-- 
One thing that is clear: it's all down hill from here 

Re: [O] Links in #+caption: lines

[Rasmus]

t...@tsdye.com (Thomas S. Dye) writes:

 Aloha all,

 Links in #+caption: lines are shown as literal links.  IIRC, they used
 to show as descriptive links.  Has this changed, or is my memory faulty?

 In any case, I'd like them to be descriptive links to keep the

 #+caption: lines as short as possible.

Maybe it's an effect of 37d2a2d1cfa58c5334eec4f7fbabc4a2f313ab33?  Cf.

  http://thread.gmane.org/gmane.emacs.orgmode/95415

In any case, unless links can be fortified in captions, I think current
behavior is OK.  Hidden links are worse, IMO.

Rasmus

-- 
Lasciate ogni speranza, voi che leggete questo.

[O] Links in #+caption: lines

[Thomas S. Dye]

Aloha all,

Links in #+caption: lines are shown as literal links.  IIRC, they used
to show as descriptive links.  Has this changed, or is my memory faulty?

In any case, I'd like them to be descriptive links to keep the
#+caption: lines as short as possible.

All the best,
Tom

-- 
T.S. Dye  Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] Links in #+caption: lines

[Thomas S. Dye]

Aloha Rasmus,

Rasmus ras...@gmx.us writes:

 t...@tsdye.com (Thomas S. Dye) writes:

 Aloha all,

 Links in #+caption: lines are shown as literal links.  IIRC, they used
 to show as descriptive links.  Has this changed, or is my memory faulty?

 In any case, I'd like them to be descriptive links to keep the

 #+caption: lines as short as possible.

 Maybe it's an effect of 37d2a2d1cfa58c5334eec4f7fbabc4a2f313ab33?  Cf.

   http://thread.gmane.org/gmane.emacs.orgmode/95415

 In any case, unless links can be fortified in captions, I think current
 behavior is OK.  Hidden links are worse, IMO.

I don't know if it is an effect of 37d2a2d.  I'm also seeing a different
background for captions, similar to the background the emacs 24 starter
kit gives me for #+begin_src and #+end_src lines.

I use links for citations, which frequently appear in captions when I
specify the source of data, etc.  The paper I'm working on now looks a
bit ungainly in the Org mode buffer due to the literal links in captions
and the weird backgrounds.

If it is necessary to choose between literal links in macros or
descriptive links in captions, perhaps there could be a switch for users
like you and me who use one but not the other?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

[O] Links Drawer

[Leonard Randall]

Hi all,
In a few functions that I use for organizing my research, I use links
drawers. This enables me to write functions that automatically insert links
in all entries matching particular criteria, or insert links directly from
the headline or anywhere else in the entry. To do this I wrote a couple of
functions. The first function is nearly identical to
org-insert-properties-drawer (I only changed a bit of regexp). It simply
inserts a LINKS drawer near the top of the entry below any clocking,
scheduling, or deadline or PROPERTIES info. It is not for interactive use.
The the other searches for a links drawer in the current entry and inserts
one if none is found. It  then inserts a link in the drawer using
org-insert-link.


Anyway I thought they might be useful for others, and I wondered if people
thought that they should be part of org-mode.  Here is the code. Don't
hesitate to give any suggestions.


(defun my-org-insert-links-drawer ()
  Insert a links drawer near the beginning of the current entry.
Inserts drawer near beginning of entry after scheduling, deadline
and clocking info and after standard logging, property and clock
drawers.
  (org-back-to-heading t)
  (looking-at org-outline-regexp)
  (let ((indent (if org-adapt-indentation
(- (match-end 0) (match-beginning 0))
  0))
(beg (point))
(re (concat ^[ \t]* org-keyword-time-regexp))
end hiddenp)
(outline-next-heading)
(setq end (point))
(goto-char beg)
(while (re-search-forward re end t))
(setq hiddenp (outline-invisible-p))
(end-of-line 1)
(and (equal (char-after) ?\n) (forward-char 1))
(while (looking-at ^[
\t]*\\(:CLOCK:\\|:LOGBOOK:\\|CLOCK:\\|:PROPERTIES:\\|:END:\\))
  (if (member (match-string 1) '(CLOCK: :END:))
  ;; just skip this line
  (beginning-of-line 2)
;; Drawer start, find the end
(re-search-forward ^\\*+ \\|^[ \t]*:END: nil t)
(beginning-of-line 1)))
(org-skip-over-state-notes)
(skip-chars-backward  \t\n\r)
(if (and (eq (char-before) ?*) (not (eq (char-after) ?\n)))
(forward-char 1))
(goto-char (point-at-eol))
(let ((inhibit-read-only t)) (insert \n:LINKS:\n:END:))
(beginning-of-line 0)
(org-indent-to-column indent)
(beginning-of-line 2)
(org-indent-to-column indent)
(beginning-of-line 0)
(if hiddenp
(save-excursion
  (org-back-to-heading t)
  (hide-entry))
  (org-flag-drawer t

(defun my-org-insert-link-in-drawer (optional complete-file link-location
default-description)
  Find or create links drawer then insert link with `org-insert-link'.
The arguments COMPlETE-FILE LINK-LOCATION and DEFAULT-DESCRIPTION
are passsed on to `org-insert-link'.  See its documentation for
information on how these arguments are handled.
  (interactive)
  ;; make sure that we are currently in an entry.
  (if (not (org-before-first-heading-p))
  ;; look for links drawer.
  (save-excursion
(org-back-to-heading t)
(let ((beg (point))
  end hiddenp)
  (outline-next-heading)
  (setq end (point))
  (backward-char 1)
  (setq hiddenp (outline-invisible-p))
  (goto-char beg)
  (unless (and (re-search-forward [ \t]*:LINKS:[ \t]*$ end t)
   (re-search-forward [ \t]*:END:[ \t]*$ end t))
;; if no links drawer found create one.
(my-org-insert-links-drawer))
  ;; go to links drawer.
  (goto-char beg)
  (re-search-forward [ \t]*:LINKS:[ \t]*$)
  ;; open new line and insert link.
  (newline)
  (org-insert-link complete-file link-location default-description)
  (if hiddenp
  (hide-entry
;; Give error if before first heading.
(error Before first heading)))



All best,
Leonard

[O] Links in tables: could the plain text also look good?

[Oleh]

Hi all,

I don't know if this issue has been raised before (it's a bit
difficult to google it).

I was just committing a single line change to an org-mode table into
git, and the diff isn't good at all: the whole table appears to have
changed. Well, not really - just a few spaces were added on each table
line because the single new line caused a need to re-align the whole
table.

So I'm thinking: if org-mode uses overlays for links to make some of
the real text invisible, why not keep the plain text aligned and use
the overlays to align the fontified text?

Having a good-looking plain text is an achievement in itself, but
using an smart allocation strategy (like std::vector growth) to add
more spaces than needed each time a column grows, would alleviate the
diff problem, i.e. the diff would show only a single line change most
of the time a line is added or removed.

I'd like some feedback on whether:

- it's done already and I just haven't enabled this behavior
- it can't be done because of some complex issue
- it can be done, but just isn't a priority

In the third case maybe some pointers on where to start implementing
would help.

regards,
Oleh

Re: [O] Links in tables: could the plain text also look good?

[Michael Brand]

Hi Oleh

On Thu, Mar 6, 2014 at 8:00 PM, Oleh ohwoeo...@gmail.com wrote:
 I was just committing a single line change to an org-mode table into
 git, and the diff isn't good at all: the whole table appears to have
 changed. Well, not really - just a few spaces were added on each table
 line because the single new line caused a need to re-align the whole
 table.

Did you try the git diff options -b and/or --color-words to not list
the table lines and/or color the columns that were only realigned?
There are many other (also color-less) word variants which might come
closer to your need. With a regexp it should be possible to omit even
realigned horizontal separator lines in tables.

Or instrument git to use an external tool like, well, Emacs ediff. To
find a solution to your need search the web for the words git difftool
ediff-files. Emacs 24.3 changed coloring of the diffs to what I find
much more convenient. See also the git command difftool and Worg
hacks How to ediff folded Org files and the entire mailing list
thread linked there, currently in this section
http://orgmode.org/worg/org-hacks.html#sec-2-1

A discussion that I didn't read yet about the git diff format

-a rb/r c
+a gx/g c

which is what I would prefer can be found here
http://git.661346.n2.nabble.com/Understanding-and-improving-word-diff-td5717239.html

 So I'm thinking: if org-mode uses overlays for links to make some of
 the real text invisible, why not keep the plain text aligned and use
 the overlays to align the fontified text?

 Having a good-looking plain text is an achievement in itself, but
 using an smart allocation strategy (like std::vector growth) to add
 more spaces than needed each time a column grows, would alleviate the
 diff problem, i.e. the diff would show only a single line change most
 of the time a line is added or removed.

 I'd like some feedback on whether:

 - it's done already and I just haven't enabled this behavior

This time no ;-)

 - it can't be done because of some complex issue
 - it can be done, but just isn't a priority

At least it would have to be optional because it would make reading
and editing Org files outside of Org mode or in Org mode with Visible
mode less fun. For this I find the current behaviour, also with
narrowed columns, a perfect solution. (Disclaimer: I hacked and use
hidestarsfile, see
http://orgmode.org/worg/org-hacks.html#fileconversion )

Michael

Re: [O] Links in tables: could the plain text also look good?

[Ilya Shlyakhter]

On 3/6/14 2:00 PM, Oleh wrote:


I was just committing a single line change to an org-mode table into
git, and the diff isn't good at all: the whole table appears to have
changed. Well, not really - just a few spaces were added on each table
line because the single new line caused a need to re-align the whole
table.


You can tell diff to ignore whitespace-only changes by using the -w option:

https://www.kernel.org/pub/software/scm/git/docs/git-diff.html

-w
--ignore-all-space
Ignore whitespace when comparing lines. This ignores differences even if 
one line has whitespace where the other line has none.

[O] Links in node-property

[Michael Brand]

Hi Nicolas

Will org-open-at-point still support links in node-property?

:PROPERTIES:
:ID:   24ac0164-3c4f-4792-93ac-aaae68a19632
:related:  [[id:15763c8f-f022-486e-9449-bac56f7aa028]]
:features: http://orgmode.org/features.html
:doc:  http://orgmode.org/org.html
:END:

Michael

Re: [O] Links in node-property

[Nicolas Goaziou]

Hello,

Michael Brand michael.ch.br...@gmail.com writes:

 Will org-open-at-point still support links in node-property?

No. According to Org syntax, there are no links in property drawers.
There are also no links in comments, example blocks, fixed-width
areas...


Regards,

-- 
Nicolas Goaziou

Re: [O] Links in node-property

[Bastien]

Hi Nicolas,

Nicolas Goaziou n.goaz...@gmail.com writes:

 Michael Brand michael.ch.br...@gmail.com writes:

 Will org-open-at-point still support links in node-property?

 No. According to Org syntax, there are no links in property drawers.
 There are also no links in comments, example blocks, fixed-width
 areas...

Believe me, there *are* links in comments, I can see them :)

Right now, hitting C-c C-o on this link

# http://orgmode.org

in an org-mode buffer produces the attached backtrace, which is
a problem /per se/ (easily fixable, I guess.)

Anyway, not supporting links in comments does not feel right, as
links in comments are both frequent and useful.

I'm sorry for the frustration it will inevitably create, but at this
stage I suggest to simply revert the commits related to the rewriting
of `org-open-at-point'.  To my knowledge, there is no bug that this
rewrite fixes, there is no gain in speed, and only a regression (not
opening the next link) and a bug (see `org-agenda-open-link'.)

What do you think?

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  =(55 nil)
  (let ((end (org-element-property :end context))) (= (save-excursion (if 
(invisible-p (point)) (progn (goto-char (next-single-property-change (point) 
(quote invisible) nil end (skip-chars-forwardend) (point)) end))
  (cond ((and (memq type (quote (headline inlinetask))) (progn (save-excursion 
(beginning-of-line) (looking-at org-complex-heading-regexp)) (or (not 
(match-beginning 5)) ( (point) (match-beginning 5) (let* ((data 
(org-offer-links-in-entry (current-buffer) (point) arg)) (links (car data)) 
(links-end (cdr data))) (if links (let ((--dolist-tail-- (if ... ... links)) 
link) (while --dolist-tail-- (setq link (car --dolist-tail--)) (search-forward 
link nil links-end) (goto-char (match-beginning 0)) (org-open-at-point) (setq 
--dolist-tail-- (cdr --dolist-tail-- (require (quote org-attach)) 
(org-attach-reveal (quote if-exists) ((let ((end (org-element-property :end 
context))) (= (save-excursion (if (invisible-p (point)) (progn (goto-char 
...))) (skip-chars-forward  end) (point)) end)) (user-error No link 
found)) ((eq type (quote timestamp)) (org-follow-timestamp-link)) ((and (memq 
type (quote (headline inlinetask))) (progn (save-excursion (beginning-of-line) 
(looking-at org-complex-heading-regexp)) (and (match-beginning 5) (= (point) 
(match-beginning 5) (org-tags-view arg (substring (match-string 5) 0 -1))) 
((eq type (quote link)) (let ((type (org-element-property :type context)) (path 
(org-element-property :path context))) (save-current-buffer (set-buffer (or 
reference-buffer (current-buffer))) (cond ((equal type file) (if 
(string-match [*?{] ...) (dired path) (apply ... path arg ...))) ((assoc type 
org-link-protocols) (funcall (nth 1 ...) path)) ((equal type help) (let (...) 
(cond ... ... ...))) ((equal type mailto) (let (... ... ... final-args) 
(apply cmd ...))) ((member type (quote ...)) (browse-url 
(org-link-escape-browser ...))) ((equal type doi) (browse-url 
(org-link-escape-browser ...))) ((equal type message) (browse-url (concat 
type : path))) ((equal type shell) (let (... ...) (if ... ... ...))) 
((equal type elisp) (let (...) (if ... ... ...))) ((equal type id) (require 
(quote ord-id)) (funcall (nth 1 ...) path)) ((member type (quote ...)) (if 
(run-hook-with-args-until-success ... path) nil (if ... ... ...) (let ... 
...))) (t (browse-url-at-point)) ((or (eq type (quote footnote-reference)) 
(and (eq type (quote footnote-definition)) (save-excursion (skip-chars-forward 
   ) (let ((begin ...)) (if begin ( ... begin) (= ... ...)) 
(org-footnote-action)) (t (user-error No link found)))
  (let* ((context (org-element-context)) type) (while (and (not (memq (setq 
type (org-element-type context)) (quote (headline inlinetask link 
footnote-definition footnote-reference timestamp (setq context 
(org-element-property :parent context (cond ((and (memq type (quote 
(headline inlinetask))) (progn (save-excursion (beginning-of-line) (looking-at 
org-complex-heading-regexp)) (or (not (match-beginning 5)) ( (point) 
(match-beginning 5) (let* ((data (org-offer-links-in-entry (current-buffer) 
(point) arg)) (links (car data)) (links-end (cdr data))) (if links (let 
((--dolist-tail-- ...) link) (while --dolist-tail-- (setq link ...) 
(search-forward link nil links-end) (goto-char ...) (org-open-at-point) (setq 
--dolist-tail-- ...))) (require (quote org-attach)) (org-attach-reveal (quote 
if-exists) ((let ((end (org-element-property :end context))) (= 
(save-excursion (if (invisible-p ...) (progn ...)) (skip-chars-forward
end) (point)) end)) (user-error No link found)) ((eq type (quote timestamp)) 
(org-follow-timestamp-link)) ((and (memq type (quote (headline inlinetask))) 
(progn (save-excursion (beginning-of-line) (looking-at 
org-complex-heading-regexp)) (and (match-beginning 5) (= (point) 
(match-beginning 5) 

Re: [O] Links in node-property

[Nicolas Goaziou]

Bastien b...@gnu.org writes:

 Believe me, there *are* links in comments, I can see them :)

 Right now, hitting C-c C-o on this link

 # http://orgmode.org

 in an org-mode buffer produces the attached backtrace, which is
 a problem /per se/ (easily fixable, I guess.)

My bad. This should now be fixed.

 Anyway, not supporting links in comments does not feel right, as
 links in comments are both frequent and useful.

Comments, by definition, are dead data. It just doesn't make sense to
expect to have an active link, or timestamp, or whatever inside. If you
put an active timestamp in a comment, you don't expect it to show in the
agenda, right?

If you need live non-exportable data, you can stuff it in a regular
drawer.

 I'm sorry for the frustration it will inevitably create, but at this
 stage I suggest to simply revert the commits related to the rewriting
 of `org-open-at-point'.  To my knowledge, there is no bug that this
 rewrite fixes, there is no gain in speed, and only a regression (not
 opening the next link) and a bug (see `org-agenda-open-link'.)

 What do you think?

I think that if we reverted each buggy commit, we wouldn't be far from
the very first commit in Org.

Anyway, I suggest to either explain to me why opening the next link is
needed, so we can discuss on how to do it best, or implement the feature
yourself, as you intended to do a few minutes ago.

In any case, I don't see the need to trash the few hours of work
I invested already in this (well, almost) working function.


Regards,

-- 
Nicolas Goaziou

Re: [O] Links sorting and exporting.

[Bastien]

Hi Matthew,

Matthew Sauer improv.philoso...@gmail.com writes:

 Thoughts on this?

I didn't get the idea.  Can you restate it with a few words?

Thanks!

-- 
 Bastien

Re: [O] Links sorting and exporting.

[Matthew Sauer]

Bastien,

What I am thinking is of a way to save a web bookmark in a file or two and
then based on meta-tag have them exported into a html file.  In other
words, if I have a file with bookmarks that has tags: apple, fruit, orange,
dog, horse, pet, animal, etc then it would create a html page named for the
tag and any bookmark that has that tag would be present in it.   The last
piece would be to generate a front page that would have a relative link to
those pages.  This would be a way of publishing links for others in my
group to use.


On Mon, Feb 3, 2014 at 3:22 AM, Bastien b...@gnu.org wrote:

 Hi Matthew,

 Matthew Sauer improv.philoso...@gmail.com writes:

  Thoughts on this?

 I didn't get the idea.  Can you restate it with a few words?

 Thanks!

 --
  Bastien

Re: [O] Links sorting and exporting.

[Bastien]

Hi Matthew,

Matthew Sauer improv.philoso...@gmail.com writes:

 What I am thinking is of a way to save a web bookmark in a file or
 two and then based on meta-tag have them exported into a html file.
  In other words, if I have a file with bookmarks that has tags:
 apple, fruit, orange, dog, horse, pet, animal, etc then it would
 create a html page named for the tag and any bookmark that has that
 tag would be present in it.   The last piece would be to generate a
 front page that would have a relative link to those pages.  This
 would be a way of publishing links for others in my group to use.

I think most of the pieces are already in place for this:

- you can use org-protocol.el to capture a URL from a web browser as
  a subtree in an Org file ;

- you can tag the capture at will (or define several capture keys)
  triggered by the button in your browser

- you can define a view for all subtrees tagged :bmk: -- and filter
  this view for other tags -- e.g. for a subtree with :bmk:apple:, you
  first list all :bmk: subtrees, then hit '/' to list :apple:
  subtrees.

- from the agenda view, C-x C-w mybookmarkfile.org RET will store all
  listed subtrees in a new Org file.

So maybe this is just a matter of refining this workflow.

HTH,
  
-- 
 Bastien

[O] Links sorting and exporting.

[Matthew Sauer]

I have conceived of an idea that I want to build into the ORG framework.

The problem I am trying to solve: I have a variety of links that I use on a
regular basis.  I am wanting to be able to invoke a link generation command
that will store them in a bookmarks.org file (or it could be a user defined
file).  However, searching them isn't always easy and I want to be able to
publish them as a resource for a group of users.  I can search them easy
enough in org but others can't.

Idea I have:  It would be interesting to have org, or maybe it would have
to be an external function, that would go through a file or set of
files(user defined list?) (work, group @ work, home) and generate a main
bookmark page (in the example, one for work, one for group @ work, and one
for home) that links to a file that is named for that tag and contains an
html file of each link that contains that tag.  This could cause some
things too appear in more than one file, for example, something might
appear in CIFS and performance but it's related to each topic.   This could
be manually triggered or scheduled for updating and publishing out to a web
server.

I am thinking that we would have a user defined file list in the
configuration, would need to go find all the unique tags in each file and
make the launch page for each file by generating relative links to the sub
pages, the collect the list of links for each tag generating the sub page.
 Thinking it would be best to generate these in .org format and then
publish them out in html to a user defined location.

Thoughts on this?  Is this already done?  I know some parts of it are
already present and I just need to make glue for those parts.  I think the
part that will need to be constructed outside of the glue is the sorting
and generation of separate files

[O] links and anchors

[Rustom Mody]

Context is html export

I have a file of quotes like the following
--
* Declarative vs Imperative
Never tell people  how to do things. Tell them what to do and they will
surprise you with their ingenuity  \\
General G.S.Patton (1941)
-
which I link from another file

Now if
1. I put the anchor declarative inside the body then the header
vanishes on following the link
2. If I write it as
* Declarative and Imperative declarative
it works well but the header looks ugly at least in org though not on export
3. Looking at the generated html I see the autogenerated sec-9 for
that para can be used.  But then Ive to keep synced with what is
auto-generated.

What do people use for this situation?

-- 
http://www.the-magus.in
http://blog.languager.org

Re: [O] links and anchors

[Nicolas Goaziou]

Hello,

Rustom Mody rustompm...@gmail.com writes:

 Context is html export

 I have a file of quotes like the following
 --
 * Declarative vs Imperative
 Never tell people  how to do things. Tell them what to do and they will
 surprise you with their ingenuity  \\
 General G.S.Patton (1941)
 -
 which I link from another file

 Now if
 1. I put the anchor declarative inside the body then the header
 vanishes on following the link
 2. If I write it as
 * Declarative and Imperative declarative
 it works well but the header looks ugly at least in org though not on export
 3. Looking at the generated html I see the autogenerated sec-9 for
 that para can be used.  But then Ive to keep synced with what is
 auto-generated.

 What do people use for this situation?

Did you try custom-id? See section 4.2 in manual.


Regards,

-- 
Nicolas Goaziou

Re: [O] links and anchors

[Rustom Mody]

On Fri, Dec 27, 2013 at 4:59 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 Hello,

 Rustom Mody rustompm...@gmail.com writes:

 Context is html export

 I have a file of quotes like the following
 --
 * Declarative vs Imperative
 Never tell people  how to do things. Tell them what to do and they will
 surprise you with their ingenuity  \\
 General G.S.Patton (1941)
 -
 which I link from another file

 Now if
 1. I put the anchor declarative inside the body then the header
 vanishes on following the link
 2. If I write it as
 * Declarative and Imperative declarative
 it works well but the header looks ugly at least in org though not on export
 3. Looking at the generated html I see the autogenerated sec-9 for
 that para can be used.  But then Ive to keep synced with what is
 auto-generated.

 What do people use for this situation?

 Did you try custom-id? See section 4.2 in manual.


 Regards,

 --
 Nicolas Goaziou

Thanks Nicholas -- just the thing!
[And about time I started learning about properties :D ]

Re: [O] Links to headings not generated in Tables

[Luke Crook]

Hi Nicolas,

What about the following code.  In the following, 1 and 2 are not
appearing in the HTML or the Latex exorts.



* test
  One, [[1]] and two, [[2]].


* blee

| ID| Descr | Descr |
|---+---+---|
| 1 | One   | One   |
| 2 | Two   | Two   |



On Thu, Nov 21, 2013 at 1:04 PM, Nick Dokos ndo...@gmail.com wrote:

 Luke Crook l...@balooga.com writes:

  Nicolas Goaziou n.goaziou at gmail.com writes:
 
 
  Hello,
 
  Luke Crook luke at balooga.com writes:
 
   Hi Nicolas, I'm definitely using 8.2.2, as reported by org-version.
 
  OK. Then could you provide an ECM? I'm unable to reproduce the problem.
 
  Regards,
 
 
 
  Hi Nicolas,
 
  The first two work correctly, the third does not generate a link for me.
 
 
 
  | [[id:6920d682-963f-412b-927b-af7dcfd57c79][Code 13]]  |
  | [[*Code 13]] |
  | [[*Code 13][Code 13]]  |
 
 
  *** Code 13
  :PROPERTIES:
  :ID:   6920d682-963f-412b-927b-af7dcfd57c79
  :END:

 It does for me - here's the table in the HTML output:

 --8---cut here---start-8---
 table border=2 cellspacing=0 cellpadding=6 rules=groups
 frame=hsides


 colgroup
 col  class=left /
 /colgroup
 tbody
 tr
 td class=lefta href=#sec-1Code 13/a/td
 /tr

 tr
 td class=lefta href=#sec-11/a/td
 /tr

 tr
 td class=lefta href=#sec-1Code 13/a/td
 /tr
 /tbody
 /table
 --8---cut here---end---8---

 Org-mode version 8.2.3c (release_8.2.3c-256-g5ea022.dirty @
 /home/nick/elisp/org-mode/lisp/)

 Nick

Re: [O] Links to headings not generated in Tables

[Luke Crook]

Here is the html export.  The anchor is generated, but with no text.

a id=1 name=1/a/td

thead
tr
th scope=col class=leftID/th
th scope=col class=leftDescr/th
th scope=col class=leftDescr/th
/tr
/thead
tbody
tr
td class=lefta id=1 name=1/a/td
td class=leftOne/td
td class=leftOne/td
/tr
 tr
td class=lefta id=2 name=2/a/td
td class=leftTwo/td
td class=leftTwo/td
/tr
/tbody
/table



On Thu, Dec 19, 2013 at 11:12 AM, Luke Crook l...@balooga.com wrote:

 Hi Nicolas,

 What about the following code.  In the following, 1 and 2 are not
 appearing in the HTML or the Latex exorts.



 * test
   One, [[1]] and two, [[2]].


 * blee

 | ID| Descr | Descr |
 |---+---+---|
 | 1 | One   | One   |
 | 2 | Two   | Two   |



 On Thu, Nov 21, 2013 at 1:04 PM, Nick Dokos ndo...@gmail.com wrote:

 Luke Crook l...@balooga.com writes:

  Nicolas Goaziou n.goaziou at gmail.com writes:
 
 
  Hello,
 
  Luke Crook luke at balooga.com writes:
 
   Hi Nicolas, I'm definitely using 8.2.2, as reported by org-version.
 
  OK. Then could you provide an ECM? I'm unable to reproduce the problem.
 
  Regards,
 
 
 
  Hi Nicolas,
 
  The first two work correctly, the third does not generate a link for me.
 
 
 
  | [[id:6920d682-963f-412b-927b-af7dcfd57c79][Code 13]]  |
  | [[*Code 13]] |
  | [[*Code 13][Code 13]]  |
 
 
  *** Code 13
  :PROPERTIES:
  :ID:   6920d682-963f-412b-927b-af7dcfd57c79
  :END:

 It does for me - here's the table in the HTML output:

 --8---cut here---start-8---
 table border=2 cellspacing=0 cellpadding=6 rules=groups
 frame=hsides


 colgroup
 col  class=left /
 /colgroup
 tbody
 tr
 td class=lefta href=#sec-1Code 13/a/td
 /tr

 tr
 td class=lefta href=#sec-11/a/td
 /tr

 tr
 td class=lefta href=#sec-1Code 13/a/td
 /tr
 /tbody
 /table
 --8---cut here---end---8---

 Org-mode version 8.2.3c (release_8.2.3c-256-g5ea022.dirty @
 /home/nick/elisp/org-mode/lisp/)

 Nick

Re: [O] Links to headings not generated in Tables

[Nicolas Goaziou]

Hello,

Luke Crook l...@balooga.com writes:

 What about the following code.  In the following, 1 and 2 are not
 appearing in the HTML or the Latex exorts.



 * test
   One, [[1]] and two, [[2]].


 * blee

 | ID| Descr | Descr |
 |---+---+---|
 | 1 | One   | One   |
 | 2 | Two   | Two   |

This is the expected behaviour. Targets are always invisible. See
section 4.2 in manual.


Regards,

-- 
Nicolas Goaziou

Re: [O] Links to headings not generated in Tables

[Luke Crook]

Ok.  I feel quite quite silly now.

Thanks
/Luke





On Thu, Dec 19, 2013 at 12:48 PM, Nicolas Goaziou n.goaz...@gmail.comwrote:

 Hello,

 Luke Crook l...@balooga.com writes:

  What about the following code.  In the following, 1 and 2 are not
  appearing in the HTML or the Latex exorts.
 
 
 
  * test
One, [[1]] and two, [[2]].
 
 
  * blee
 
  | ID| Descr | Descr |
  |---+---+---|
  | 1 | One   | One   |
  | 2 | Two   | Two   |

 This is the expected behaviour. Targets are always invisible. See
 section 4.2 in manual.


 Regards,

 --
 Nicolas Goaziou