[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

[O] CUSTOM_ID vs ID

[Nathan Neff]

Hello all,

I've often been confused why org-mode has both a CUSTOM_ID
and a ID property.  I mean, why not just use one or the other name?

When would I ever have both an ID and a CUSTOM_ID property for a heading?

Thanks,
--Nate

Re: [O] [RFC] Link-type for attachments, more attach options

[Ihor Radchenko]

Hi,

> ATTACH_DIR_INHERIT is no longer supported and is +removed.

I just found that removing ATTACH_DIR_INHERIT broke my current
configuration. I do not use ATTACH_DIR property - all the attachment
folders are created using ID. Also, I use ID property to store links to
entries. Therefore, inheriting ATTACH_DIR does nothing for me and
inheriting ID always gives the current entry's id value. At the end, I
cannot make a common attachment directory for the whole subtree, like I
was able to do with ATTACH_DIR_INHERIT.

Regards,
Ihor


Gustav Wikström  writes:

> Hi!
>
>> > +  (if should-get
>> > +  (progn (message "Running git annex get \"%s\"." path-relative)
>> > + (call-process "git" nil nil nil "annex" "get" path-relative))
>> > +(error "File %s stored in git annex but it is not available, and was 
>> > not
>> retrieved"
>> > +   path))
>> 
>> Nitpick:
>> 
>> (unless should-get
>>  (error "File %S stored in git annex but unavailable" path))
>> (message "Running git annex get %S." path-relative)
>> (call-process ...)
>
> Ok, fixed.
>
>> > +Selective means to respect the inheritance setting in
>> > +`org-use-property-inheritance'."
>> >:group 'org-attach
>> > +  :type '(choice
>> > +(const :tag "Don't use inheritance" nil)
>> > +(const :tag "Inherit parent node attachments" t)
>> > +(const :tag "Respect org-use-property-inheritance" selective)
>> > +)
>> 
>> Dangling paren spotted.
>
> Fixed.
>
>> > +  (setq attachment (or (org-attach-dir)
>> > + (quote  "Can't find an existing attachment-folder")))
>> 
>> You forgot to remove that weird quote. Maybe you meant `error'?
>
> Hmm, actually no. But the code is pretty bad so I've refactored it a
> bit. The purpose of the change is for org-attach to give an indication
> of the active attachment path, or to signal that there is none. But
> for that I don't really need a separate variable. Thus it's slightly
> refactored for code-clarity.
>
>> > +(if attach-dir
>> > +  (progn (if (not (file-directory-p attach-dir))
>> > + (make-directory attach-dir t))
>> > + attach-dir)
>> > +  (error "No attachment directory is associated with the current 
>> > node"
>> 
>> Same nitpick as above:
>> 
>> (unless attach-dir
>>  (error "No attachment ..."))
>> (if (file-directory-p attach-dir) attach-dir
>>   (make-directory attach-dir))
>
> Ok, fixed.
>
>> > +(defun org-attach-dir-from-id (id)
>> > +  "Creates a path based on `org-attach-id-dir' and ID."
>> > +  (expand-file-name
>> > +   (funcall org-attach-id-to-path-function id)
>> > +   (expand-file-name org-attach-id-dir)))
>> 
>> Creates path -> Return a file name.
>
> Fixed.
>
>> > +of the entry.  Creates relative links if `org-attach-dir-relative'
>> > +is t.
>> 
>> Nitpick:
>> 
>>   is t -> is non-nil.
>
> Ah, true. Fixed.
>
>> If tests pass, feel free to apply the patches in master. Thank you!
>
> Got it. Aaand one test failure. That test is unrelated to my changes
> though, and fails also on master. Test-org-table/copy-down. So I'll
> try to apply my patch asap regardless of that one test failing.
>
> Just one more thing - a few days back I added a row to lisp/ox-html.el
> regarding inline-images. I'm including that change as well since it
> relates 100% to the new attachment link. I looked in the other
> export-backends too but didn't add anything due to lack of time for
> testing. Maybe the additions for other backends is as trivial as for
> html. So someone who regularly export to those backends might want to
> suggest patches for them to make attachment links to images actually
> display as images? 

>
> Final patches attached for full disclosure before applying them.
>
>> 
>> Regards,
>> 
>> --
>> Nicolas Goaziou
> From 3cbe356b0a9d1a98848df0fa09ba306392995b88 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Gustav=20Wikstr=C3=B6m?= 
> Date: Sun, 26 May 2019 03:34:34 +0200
> Subject: [PATCH 1/2] org-test, test-org-element, test-org, test-ox,
>  test-property-inheritance
>
> * org-test.el:
>
> Fix org-test-with-temp-text-in-file.  Make it work with , as
> some tests already expect it to do!  Also make it fail more gracefully
> by still removing temporary buffers and files.
>
> Improve org-test-in-example-file.  Make it behave similar to
> org-test-with-temp-text and org-test-with-temp-text-in-file, in that
> it will return the last evaluated expression.
>
> * testing/lisp/test-org-element.el
>
> Fix a temp-text strings so that it doesn't have an initial newline.
>
> * testing/lisp/test-org.el
>
> Minor cleanup to align code-structure with other tests.  Nothing
> changes in the test execpt style.
>
> * testing/lisp/test-ox.el
>
> Fix a couple of temp-text strings so that they don't have initial
> newlines.
>
> ** test-org-export/expand-include
>
> Test specification was wrong, due to org-test-with-temp-text-in-file
> not previously working with .  Since that is fixed in this
> patch the 

Re: [O] org-links for Gnus in imap with Gmail (for a convenient todo.org list)

[Joseph Vidal-Rosset]

Le ven. 26 juil. 2019  à 07:30:38 , Bob Newell 
a envoyé ce message:
> Aloha,
>
> I too came across this long ago. I like a 'zero inbox' and so I archive
> (or delete!) my gmail after reading. And indeed, when you move from
> INBOX to "All Mail" an org-link to INBOX will no longer function.
>
> I use Gnus and do something rather simple and easy:
>
> (defun changegroupinemaillink (args)
>   (setcar args
> (replace-regexp-in-string
>  "gmail.com:INBOX"
>  "gmail.com:[Gmail]/All Mail" (car args)))
>   args
> )
> (advice-add 'org-gnus-article-link :filter-args #'changegroupinemaillink)
>
> After this, links point to All Mail and the mail will always be found.

Many thanks for your message Bob (I know your impressive website that is
helpful for org-mode, thanks also for that).

My problem is how can I change the following code:

(setq org-capture-templates
  '(
("t" "todo" entry (file+headline "~/Dropbox/Orgzly/todo.org" "Tasks")
 "* TODO [#A] %?\n 
[[~/Dropbox/Orgzly/links.org::%(org-insert-time-stamp (org-read-date nil t 
\"%:date\"))]] \n* %(org-insert-time-stamp (org-read-date nil t \"%:date\")) %a 
"
 )
)
  )

in order to get  All Mail (or Tous les messages in  my case) directly in
the produced link once "t" key is entered?

I have tried to do it with  the function hs/replace that I have defined,
without success. I  guess that it is  of course possible, but  it is not
easy for me.

Your help will be again very welcome.

 Best wishes,
-- 
Jo.

[O] BUG (smallish) The exemple of the documentation of the LaTeX LANGUAGE option is incorrect

[Emmanuel Charpentier]

The current (org-version=9.2.4) documentation of the LANGUAGE option
for LaTeX export gives this example :

#+begin_example
   (add-to-list org-latex-package-alist
'("AUTO" "babel" t ("pdflatex")))
   (add-to-list org-latex-package-alist
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_example

It should be:

#+begin_example
#+bensert the example in agin_src emacs-lisp :exports none :results
none
  (add-to-list 'org-latex-packages-alist
   '("AUTO" "babel" t ("pdflatex")))
  (add-to-list 'org-latex-packages-alist
   '("AUTO" "polyglossia" t ("xelatex" "lualatex")))
#+end_src
#+end_example

i. e.:
  * The name of the list has to be quoted.
  * The exact list name has as "s" after "package".
  * I'd give a full ~emacs-lisp~ snippet (but I agree that this is
disputable...).

Care fo a formal patch ?

HTH,

--
Emmanuel Charpentier