RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: stardiviner > Sent: den 19 januari 2020 05:28 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > [...] > > From the source code, it seems indeed still original code logic. > > Then I checked out my Emacs init git log, confirmed it is ~'attached~ > option value at first time. So this is my mistake. > > Because this new ~attachment:~ link type has potential issues like on > exporting. The issue with attachment links in the exporters should be fixed since the report of the export issues you sent a short while back. Any external exporter you use may ofc still need to be updated for attachment links. > So I decided to still use old ~file:~ link type. So I thought should set > ~org-attach-store-link-p~ to ~t~. It indeed use ~file:~ link type instead > of ~attachment:~ now. But the store link behavior affected. > > So the problem is how can I use both ~file:~ link type for attachments and > use this new attached store link? Understood, and I see no issue with complementing org-attach-store-link-p with another option. One that stores a file link to the attached files location. Pushed a change for that just now.
Re: [O] FW: [RFC] Link-type for attachments, more attach options
org-stored-links))) (if visit-dir (dired attach-dir) (message "File %S is now an attachment." basename) @@ -642,12 +638,6 @@ See `org-attach-open'." Basically, this adds the path to the attachment directory." (expand-file-name file (org-attach-dir))) -(defun org-attach-expand-link (file) - "Return a file link pointing to the current entry's attachment file FILE. -Basically, this adds the path to the attachment directory, and a \"file:\" -prefix." - (concat "file:" (org-attach-expand file))) - (org-link-set-parameters "attachment" :follow #'org-attach-open-link :export #'org-attach-export-link #+end_src >From the source code, it seems indeed still original code logic. Then I checked out my Emacs init git log, confirmed it is ~'attached~ option value at first time. So this is my mistake. Because this new ~attachment:~ link type has potential issues like on exporting. So I decided to still use old ~file:~ link type. So I thought should set ~org-attach-store-link-p~ to ~t~. It indeed use ~file:~ link type instead of ~attachment:~ now. But the store link behavior affected. So the problem is how can I use both ~file:~ link type for attachments and use this new attached store link? > >> -Original Message- >> From: stardiviner >> Sent: den 18 januari 2020 15:56 >> To: Gustav Wikström >> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >> >> >> stardiviner writes: >> >> I finally figured out why the link always failed. Because it use wrong >> variable which is old filename path. I attached a patch. >> >> > Gustav Wikström writes: >> > >> >> Hi, >> >> >> >>> -Original Message- >> >>> From: stardiviner >> >>> Sent: den 15 januari 2020 07:21 >> >>> To: Gustav Wikström >> >>> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >> >>> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach >> >>> options >> >>> >> >>> [...] >> >>> >> >>> >> I found when I set option ~(setq org-attach-store-link-p t)~. >> >>> >> Then attach a file, store file link with =[C-c C-l]=. The stored >> >>> >> link. I open this link got error "No such file: ". I tested >> >>> >> this with minimal Emacs config. confirmed this problem. >> >>> >> >> >>> > >> >>> > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) >> >>> > and >> >>> with only that single customization it works for me. I'm testing it >> >>> in linux. A wild guess.. Could it be that you used the move >> >>> operation instead of the copy operation when attaching the file? >> >>> > >> >>> > Regards >> >>> > Gustav >> >>> >> >>> Did you reproduce this issue with =emacs -q= ? That is a built-in >> >>> Org Mode version which does not contains the latest version =org- >> attach.el=. >> >>> >> >>> Here is my minimal Emacs config: >> >>> >> >>> [...] >> >>> >> >>> ;;== >> >>> == >> >>> == >> >>> ;;; Here is org-attach.el customization >> >>> >> >>> (require 'org-attach) >> >>> >> >>> ;; store link auto with `org-store-link' using `file:' link type or >> >>> `attachment:' link type. >> >>> (setq org-attach-store-link-p 'attached) (setq >> >>> org-attach-dir-relative t) (setq org-attach-preferred-new-method >> >>> 'ask) #+end_src >> >>> >> >>> #+begin_src sh :eval no >> >>> emacs -q -l '~/.config/emacs/minimal-init.el' >> >>> #+end_src >> >> >> > >> >> Hmm, in the first mail you said that you set org-attach-store-link-p >> >> to t, but in your config it says 'attached. >> > >> > Sorry about this. >> > >> >> I've tried with a minimal config as well (using emacs -q because I >> >> build the newest org mode version into the emacs >> >> folder) and can only reproduce your issue when using the attached >> >> option for org-attach-store-link-p and then inserting that link with >> >> C-c C-l /in another heading/. Pasting the link in another heading is >> >> expected to break since the attachment link is context dependent (i.e. >> requires an attachment folder). >> >> Makes sense? If I'm still misunderstanding your use-case, would you >> >> care to describe the steps to reproduce it more in detail? >> > >> > After updated commit, don't know why, but all links worked again. I'm >> > not good at expressing thanks, but you got all my thanks on this. :) >> > >> >> Regards >> >> Gustav >> >> >> >> -- >> [ stardiviner ] >>I try to make every word tell the meaning what I want to express. >> >>Blog: https://stardiviner.github.io/ >>IRC(freenode): stardiviner, Matrix: stardiviner >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >> -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi! org-attach-store-link-p with option t is supposed to store a link to the original location (i.e. the location the file was/is in before it was attached to the node. That was the default before I started working with attachments I believe. Haven't ever used that feature myself but the patch you provide would change the functionality which I don't think is correct. It would also not match the documentation any longer. See the documentation for the customization parameter: #+begin_src emacs-lisp (defcustom org-attach-store-link-p nil "Non-nil means store a link to a file when attaching it." :group 'org-attach :version "24.1" :type '(choice (const :tag "Don't store link" nil) (const :tag "Link to origin location" t) (const :tag "Link to the attach-dir location" attached))) #+end_src Regards Gustav > -Original Message- > From: stardiviner > Sent: den 18 januari 2020 15:56 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > > stardiviner writes: > > I finally figured out why the link always failed. Because it use wrong > variable which is old filename path. I attached a patch. > > > Gustav Wikström writes: > > > >> Hi, > >> > >>> -Original Message- > >>> From: stardiviner > >>> Sent: den 15 januari 2020 07:21 > >>> To: Gustav Wikström > >>> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > >>> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach > >>> options > >>> > >>> [...] > >>> > >>> >> I found when I set option ~(setq org-attach-store-link-p t)~. > >>> >> Then attach a file, store file link with =[C-c C-l]=. The stored > >>> >> link. I open this link got error "No such file: ". I tested > >>> >> this with minimal Emacs config. confirmed this problem. > >>> >> > >>> > > >>> > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) > >>> > and > >>> with only that single customization it works for me. I'm testing it > >>> in linux. A wild guess.. Could it be that you used the move > >>> operation instead of the copy operation when attaching the file? > >>> > > >>> > Regards > >>> > Gustav > >>> > >>> Did you reproduce this issue with =emacs -q= ? That is a built-in > >>> Org Mode version which does not contains the latest version =org- > attach.el=. > >>> > >>> Here is my minimal Emacs config: > >>> > >>> [...] > >>> > >>> ;;== > >>> == > >>> == > >>> ;;; Here is org-attach.el customization > >>> > >>> (require 'org-attach) > >>> > >>> ;; store link auto with `org-store-link' using `file:' link type or > >>> `attachment:' link type. > >>> (setq org-attach-store-link-p 'attached) (setq > >>> org-attach-dir-relative t) (setq org-attach-preferred-new-method > >>> 'ask) #+end_src > >>> > >>> #+begin_src sh :eval no > >>> emacs -q -l '~/.config/emacs/minimal-init.el' > >>> #+end_src > >> > > > >> Hmm, in the first mail you said that you set org-attach-store-link-p > >> to t, but in your config it says 'attached. > > > > Sorry about this. > > > >> I've tried with a minimal config as well (using emacs -q because I > >> build the newest org mode version into the emacs > >> folder) and can only reproduce your issue when using the attached > >> option for org-attach-store-link-p and then inserting that link with > >> C-c C-l /in another heading/. Pasting the link in another heading is > >> expected to break since the attachment link is context dependent (i.e. > requires an attachment folder). > >> Makes sense? If I'm still misunderstanding your use-case, would you > >> care to describe the steps to reproduce it more in detail? > > > > After updated commit, don't know why, but all links worked again. I'm > > not good at expressing thanks, but you got all my thanks on this. :) > > > >> Regards > >> Gustav > >> > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
stardiviner writes: I finally figured out why the link always failed. Because it use wrong variable which is old filename path. I attached a patch. > Gustav Wikström writes: > >> Hi, >> >>> -Original Message- >>> From: stardiviner >>> Sent: den 15 januari 2020 07:21 >>> To: Gustav Wikström >>> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >>> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >>> >>> [...] >>> >>> >> I found when I set option ~(setq org-attach-store-link-p t)~. Then >>> >> attach a file, store file link with =[C-c C-l]=. The stored link. I >>> >> open this link got error "No such file: ". I tested this with >>> >> minimal Emacs config. confirmed this problem. >>> >> >>> > >>> > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and >>> with only that single customization it works for me. I'm testing it in >>> linux. A wild guess.. Could it be that you used the move operation instead >>> of the copy operation when attaching the file? >>> > >>> > Regards >>> > Gustav >>> >>> Did you reproduce this issue with =emacs -q= ? That is a built-in Org Mode >>> version which does not contains the latest version =org-attach.el=. >>> >>> Here is my minimal Emacs config: >>> >>> [...] >>> >>> ;; >>> == >>> ;;; Here is org-attach.el customization >>> >>> (require 'org-attach) >>> >>> ;; store link auto with `org-store-link' using `file:' link type or >>> `attachment:' link type. >>> (setq org-attach-store-link-p 'attached) (setq org-attach-dir-relative t) >>> (setq org-attach-preferred-new-method 'ask) #+end_src >>> >>> #+begin_src sh :eval no >>> emacs -q -l '~/.config/emacs/minimal-init.el' >>> #+end_src >> > >> Hmm, in the first mail you said that you set org-attach-store-link-p to t, >> but >> in your config it says 'attached. > > Sorry about this. > >> I've tried with a minimal config as well >> (using emacs -q because I build the newest org mode version into the emacs >> folder) and can only reproduce your issue when using the attached option for >> org-attach-store-link-p and then inserting that link with C-c C-l /in another >> heading/. Pasting the link in another heading is expected to break since the >> attachment link is context dependent (i.e. requires an attachment folder). >> Makes sense? If I'm still misunderstanding your use-case, would you care to >> describe the steps to reproduce it more in detail? > > After updated commit, don't know why, but all links worked again. I'm not good > at expressing thanks, but you got all my thanks on this. :) > >> Regards >> Gustav >> -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >From 006583a83bc3b05b28ed1ad3610081066c0b1f95 Mon Sep 17 00:00:00 2001 From: stardiviner Date: Sat, 18 Jan 2020 22:51:53 +0800 Subject: [PATCH] Fix org-attach store link use old filename --- lisp/org-attach.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index 6bb438c72..c3d3ecda9 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -504,8 +504,8 @@ METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from (file-name-nondirectory fname)) org-stored-links)) ((eq org-attach-store-link-p t) - (push (list (concat "file:" file) - (file-name-nondirectory file)) + (push (list (concat "file:" fname) + (file-name-nondirectory fname)) org-stored-links))) (if visit-dir (dired attach-dir) -- 2.25.0
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > Hi, > >> -Original Message- >> From: stardiviner >> Sent: den 15 januari 2020 07:21 >> To: Gustav Wikström >> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >> >> [...] >> >> >> I found when I set option ~(setq org-attach-store-link-p t)~. Then >> >> attach a file, store file link with =[C-c C-l]=. The stored link. I >> >> open this link got error "No such file: ". I tested this with >> >> minimal Emacs config. confirmed this problem. >> >> >> > >> > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and >> with only that single customization it works for me. I'm testing it in >> linux. A wild guess.. Could it be that you used the move operation instead >> of the copy operation when attaching the file? >> > >> > Regards >> > Gustav >> >> Did you reproduce this issue with =emacs -q= ? That is a built-in Org Mode >> version which does not contains the latest version =org-attach.el=. >> >> Here is my minimal Emacs config: >> >> [...] >> >> ;; >> == >> ;;; Here is org-attach.el customization >> >> (require 'org-attach) >> >> ;; store link auto with `org-store-link' using `file:' link type or >> `attachment:' link type. >> (setq org-attach-store-link-p 'attached) (setq org-attach-dir-relative t) >> (setq org-attach-preferred-new-method 'ask) #+end_src >> >> #+begin_src sh :eval no >> emacs -q -l '~/.config/emacs/minimal-init.el' >> #+end_src > > Hmm, in the first mail you said that you set org-attach-store-link-p to t, but > in your config it says 'attached. Sorry about this. > I've tried with a minimal config as well > (using emacs -q because I build the newest org mode version into the emacs > folder) and can only reproduce your issue when using the attached option for > org-attach-store-link-p and then inserting that link with C-c C-l /in another > heading/. Pasting the link in another heading is expected to break since the > attachment link is context dependent (i.e. requires an attachment folder). > Makes sense? If I'm still misunderstanding your use-case, would you care to > describe the steps to reproduce it more in detail? After updated commit, don't know why, but all links worked again. I'm not good at expressing thanks, but you got all my thanks on this. :) > Regards > Gustav > -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: stardiviner > Sent: den 15 januari 2020 07:21 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > [...] > > >> I found when I set option ~(setq org-attach-store-link-p t)~. Then > >> attach a file, store file link with =[C-c C-l]=. The stored link. I > >> open this link got error "No such file: ". I tested this with > >> minimal Emacs config. confirmed this problem. > >> > > > > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and > with only that single customization it works for me. I'm testing it in > linux. A wild guess.. Could it be that you used the move operation instead > of the copy operation when attaching the file? > > > > Regards > > Gustav > > Did you reproduce this issue with =emacs -q= ? That is a built-in Org Mode > version which does not contains the latest version =org-attach.el=. > > Here is my minimal Emacs config: > > [...] > > ;; > == > ;;; Here is org-attach.el customization > > (require 'org-attach) > > ;; store link auto with `org-store-link' using `file:' link type or > `attachment:' link type. > (setq org-attach-store-link-p 'attached) (setq org-attach-dir-relative t) > (setq org-attach-preferred-new-method 'ask) #+end_src > > #+begin_src sh :eval no > emacs -q -l '~/.config/emacs/minimal-init.el' > #+end_src Hmm, in the first mail you said that you set org-attach-store-link-p to t, but in your config it says 'attached. I've tried with a minimal config as well (using emacs -q because I build the newest org mode version into the emacs folder) and can only reproduce your issue when using the attached option for org-attach-store-link-p and then inserting that link with C-c C-l /in another heading/. Pasting the link in another heading is expected to break since the attachment link is context dependent (i.e. requires an attachment folder). Makes sense? If I'm still misunderstanding your use-case, would you care to describe the steps to reproduce it more in detail? Regards Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes:
> Hi,
>
>> -Original Message-
>> From: Emacs-orgmode On
>> Behalf Of stardiviner
>> Sent: den 13 januari 2020 14:42
>> To: emacs-orgmode@gnu.org
>> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options
>>
>>
>> I found when I set option ~(setq org-attach-store-link-p t)~. Then attach
>> a file, store file link with =[C-c C-l]=. The stored link. I open this
>> link got error "No such file: ". I tested this with minimal Emacs
>> config. confirmed this problem.
>>
>
> I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and with
> only that single customization it works for me. I'm testing it in linux. A
> wild guess.. Could it be that you used the move operation instead of the copy
> operation when attaching the file?
>
> Regards
> Gustav
Did you reproduce this issue with =emacs -q= ? That is a built-in Org Mode
version
which does not contains the latest version =org-attach.el=.
Here is my minimal Emacs config:
#+begin_src emacs-lisp :tangle "~/.config/emacs/minimal-init.el"
(package-initialize)
;;; add my init files directory
(add-to-list 'load-path "/usr/share/emacs/site-lisp/")
(add-to-list 'load-path (expand-file-name "init" user-emacs-directory))
;; recursively load init files.
(let ((default-directory (expand-file-name "init" user-emacs-directory)))
(setq load-path
(append
(let ((load-path (copy-sequence load-path))) ; shadow
(append
(copy-sequence (normal-top-level-add-to-load-path '(".")))
(normal-top-level-add-subdirs-to-load-path)))
load-path)))
(setq load-prefer-newer t)
;;; [ package.el ] -- Emacs Lisp Package Archive (ELPA)
(require 'package)
(setq package-enable-at-startup nil)
(setq package-menu-async t)
(setq package-user-dir (expand-file-name "elpa" user-emacs-directory))
;;; ELPA Mirrors
;; (setq-default package-archives
;;'(("gnu" . "https://elpa.gnu.org/packages/;)
;; ("melpa" . "http://melpa.org/packages/;)
;; ("melpa-stable" . "http://stable.melpa.org/packages/;)
;; ("marmalade" . "http://marmalade-repo.org/packages/;)
;; ("org" . "http://orgmode.org/elpa/;)))
(setq-default package-archives
'(("melpa" . "http://mirrors.tuna.tsinghua.edu.cn/elpa/melpa/;)
("org" . "http://mirrors.tuna.tsinghua.edu.cn/elpa/org/;)
("gnu" . "http://mirrors.tuna.tsinghua.edu.cn/elpa/gnu/;)))
(let* ((elpa-archives-dir (expand-file-name "elpa/archives/"
user-emacs-directory))
(elpa-gnu-archives-dir (concat elpa-archives-dir "gnu"))
(elpa-melpa-archives-dir (concat elpa-archives-dir "melpa"))
(elpa-org-archives-dir (concat elpa-archives-dir "org")))
(unless (and (file-exists-p elpa-gnu-archives-dir)
(file-exists-p elpa-melpa-archives-dir)
(file-exists-p elpa-org-archives-dir))
(package-refresh-contents)))
(package-initialize)
(add-to-list 'display-buffer-alist
'("^\\*package-build-result\\*"
(display-buffer-reuse-window display-buffer-below-selected)))
;;; Load `use-package' ahead before `package-initialize' for (use-package org
:pin manual ...).
;;; [ use-package ]
(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package))
(eval-when-compile
(require 'use-package))
(require 'bind-key) ; if you use any `:bind' variant
(use-package delight; if you use `:delight'
:ensure t)
;; (use-package deminish ; if you use `:diminish'
;; :ensure t)
(setq use-package-verbose t ; 'debug: any evaluation errors report to
`*use-package*` buffer.
use-package-always-ensure nil)
;;; use latest source code version Org Mode.
(if (not (file-exists-p "~/Code/Emacs/org-mode/lisp/"))
(progn
(use-package org
:pin org
:ensure t
:preface (setq org-modules nil)
:mode (("\\.org\\'" . org-mode)))
(use-package org-plus-contrib
:pin org
:ensure t))
;; disable Emacs built-in Org Mode
(delete (format "/usr/local/share/emacs/%s/lisp/org" emacs-version) load-path)
(delete "/usr/share/emacs/site-lisp/org/" load-path)
(use-package org
:pin manual
:load-path "~/Code/Emacs/org-mode/lisp/"
:defer t
:preface
;; Org Mode modules -- modules that should always be loaded together with
org.el.
;; t: greedy load all modules.
;; nil: disable all extra org-mode modules to speed-up Or
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: Emacs-orgmode On > Behalf Of stardiviner > Sent: den 13 januari 2020 14:42 > To: emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > > I found when I set option ~(setq org-attach-store-link-p t)~. Then attach > a file, store file link with =[C-c C-l]=. The stored link. I open this > link got error "No such file: ". I tested this with minimal Emacs > config. confirmed this problem. > I cannot reproduce this. In my try with a minimal Emacs (emacs -q) and with only that single customization it works for me. I'm testing it in linux. A wild guess.. Could it be that you used the move operation instead of the copy operation when attaching the file? Regards Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
I found when I set option ~(setq org-attach-store-link-p t)~. Then attach a file, store file link with =[C-c C-l]=. The stored link. I open this link got error "No such file: ". I tested this with minimal Emacs config. confirmed this problem. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
stardiviner writes: > I found another problem, =[C-c C-a d]= does not give out delete available > attachment files. Maybe other places is affected, suggest you check out other > places. Ehh, sorry, today I found I can use this again. Weird that yesterday I got nothing. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
I found another problem, =[C-c C-a d]= does not give out delete available attachment files. Maybe other places is affected, suggest you check out other places. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: >> -Original Message- >> From: Emacs-orgmode On >> Behalf Of stardiviner >> Sent: den 15 december 2019 15:26 >> To: Gustav Wikström >> Cc: emacs-orgmode@gnu.org >> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >> >> ... >> >> I figured out why on my side inline image does not work. >> >> When have link with description, the inline image does not work. When has >> no link description, inline image works. >> >> Here is an example: >> >> #+begin_src org >> # link work for inline image >> [[attachment:screenshot.png]] >> >> # inline image does not work >> [[attachment:screenshot.png][description]] >> #+end_src >> >> I tested by EMC, found this is caused by some option. I will figure it >> out. Thanks! > > FWIW, I see the same behavior as you do when I add descriptions. The same > seems to > apply for file-links. I haven't looked it up to see if that's intended > though. Just > wanted to share how it works for me, if you're scratching you're head over > this! > > Actually... Not wanting to push the "Send" button without looking into the > manual, I > found the following in the "Images" section: > > "An image is a link to an image file(1) that does not have a > description part" > > See [[info:org#Images]] > > Regards > Gustav I read Org Info manual before, forgot most things, just put memory into usual behavior now. I will read Org Info manual again. :) glade you figure out my wrong point, thanks. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: [O] FW: [RFC] Link-type for attachments, more attach options
> -Original Message- > From: Emacs-orgmode On > Behalf Of stardiviner > Sent: den 15 december 2019 15:26 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > ... > > I figured out why on my side inline image does not work. > > When have link with description, the inline image does not work. When has > no link description, inline image works. > > Here is an example: > > #+begin_src org > # link work for inline image > [[attachment:screenshot.png]] > > # inline image does not work > [[attachment:screenshot.png][description]] > #+end_src > > I tested by EMC, found this is caused by some option. I will figure it > out. Thanks! FWIW, I see the same behavior as you do when I add descriptions. The same seems to apply for file-links. I haven't looked it up to see if that's intended though. Just wanted to share how it works for me, if you're scratching you're head over this! Actually... Not wanting to push the "Send" button without looking into the manual, I found the following in the "Images" section: "An image is a link to an image file(1) that does not have a description part" See [[info:org#Images]] Regards Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > Hmm, inline images work for attachment links on my side on Org mode master. > > I considered keeping the file link option but ruled against it in the end. I > could remove some complexity from the code in the end due to it. > > Don't know why attachments aren’t expanded as images for you... > I figured out why on my side inline image does not work. When have link with description, the inline image does not work. When has no link description, inline image works. Here is an example: #+begin_src org # link work for inline image [[attachment:screenshot.png]] # inline image does not work [[attachment:screenshot.png][description]] #+end_src I tested by EMC, found this is caused by some option. I will figure it out. Thanks! -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hmm, inline images work for attachment links on my side on Org mode master. I considered keeping the file link option but ruled against it in the end. I could remove some complexity from the code in the end due to it. Don't know why attachments aren’t expanded as images for you... /G > -Original Message- > From: stardiviner > Sent: den 15 december 2019 10:29 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > > Gustav Wikström writes: > > > FYI, pushed to master. Commit 26ace9004 > > > > After update, I found the new attachment link type can't display inline > image now. Maybe should keep *both* original ~file:~ link type and new > ~attachment:~ link type in stored link? WDYT, Gustav? > > -- > [ stardiviner ] >I try to make every word tell the meaning what I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > FYI, pushed to master. Commit 26ace9004 > After update, I found the new attachment link type can't display inline image now. Maybe should keep *both* original ~file:~ link type and new ~attachment:~ link type in stored link? WDYT, Gustav? -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > FYI, pushed to master. Commit 26ace9004 Thanks -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: [O] FW: [RFC] Link-type for attachments, more attach options
FYI, pushed to master. Commit 26ace9004 /Gustav > -Original Message- > From: Emacs-orgmode On Behalf > Of Gustav Wikström > Sent: den 13 december 2019 22:37 > To: numbch...@gmail.com > Cc: emacs-orgmode@gnu.org > Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options > > Hi, > > > -Original Message- > > From: stardiviner > > Sent: den 13 december 2019 14:39 > > To: Gustav Wikström > > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > > > ... > > > I tried to reproduce that using emacs -q just now but couldn't... Is there > a > > > customization that you've enabled? > > > > Aha, seems yes. I checked my config. I have option enabled: > > > > #+begin_src emacs-lisp > > (setq org-attach-store-link-p 'attached) > > #+end_src > > > > About this feature, WDYT? > > Ah, yes of course. What you propose make sense. More sense than the current > functionality! > > If no one objects I'll change the link that is stored for the 'attached option > to be an > attachment link instead of a file link. > > Regards > Gustav
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: stardiviner > Sent: den 13 december 2019 14:39 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > ... > > I tried to reproduce that using emacs -q just now but couldn't... Is there a > > customization that you've enabled? > > Aha, seems yes. I checked my config. I have option enabled: > > #+begin_src emacs-lisp > (setq org-attach-store-link-p 'attached) > #+end_src > > About this feature, WDYT? Ah, yes of course. What you propose make sense. More sense than the current functionality! If no one objects I'll change the link that is stored for the 'attached option to be an attachment link instead of a file link. Regards Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > Hi, > >> -Original Message- >> From: stardiviner >> Sent: den 12 december 2019 10:53 >> To: Gustav Wikström >> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >> >> ... >> >> For example, I press =[Ctrl-c Ctrl-a]= to attach a file. Then I press >> =[Ctrl-c >> Ctrl-l]= (~org-insert-link~) to insert link which will show a list of >> completions >> which are all link types prefix like ~attachment:~, and >> =file:data/a2//attachFile.png=. I mean the second link. it is already in >> completion list, but ~attchment:~ does not have this support. > > Hmm, I'm not sure I follow. Is it in the same suggestion list for link type > prefixes > that you also get the file-link to the newly attached file? Yes. > I tried to reproduce that using emacs -q just now but couldn't... Is there a > customization that you've enabled? Aha, seems yes. I checked my config. I have option enabled: #+begin_src emacs-lisp (setq org-attach-store-link-p 'attached) #+end_src About this feature, WDYT? > > Regards > Gustav -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
RE: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: stardiviner > Sent: den 12 december 2019 10:53 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > ... > > For example, I press =[Ctrl-c Ctrl-a]= to attach a file. Then I press =[Ctrl-c > Ctrl-l]= (~org-insert-link~) to insert link which will show a list of > completions > which are all link types prefix like ~attachment:~, and > =file:data/a2//attachFile.png=. I mean the second link. it is already in > completion list, but ~attchment:~ does not have this support. Hmm, I'm not sure I follow. Is it in the same suggestion list for link type prefixes that you also get the file-link to the newly attached file? I tried to reproduce that using emacs -q just now but couldn't... Is there a customization that you've enabled? Regards Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: > Hi stardiviner, > > It is my belief that =[Ctrl-C Ctrl-l]= already is supported. You will only > get suggestions for attachments if there are any attachments on the outline > node you're in. Or in any of its parents if inheritance is configured. > For example, I press =[Ctrl-c Ctrl-a]= to attach a file. Then I press =[Ctrl-c Ctrl-l]= (~org-insert-link~) to insert link which will show a list of completions which are all link types prefix like ~attachment:~, and =file:data/a2//attachFile.png=. I mean the second link. it is already in completion list, but ~attchment:~ does not have this support. > Regards Gustav > - > From: Emacs-orgmode on behalf > of stardiviner > Sent: Thursday, December 12, 2019 6:21:30 AM > To: emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > > Hi Gustav, > > I suggest to add support for =[Ctrl-C Ctrl-l]= like ~file:~ link type. which > will > auto in completion list. It will be convenient for user. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi stardiviner, It is my belief that =[Ctrl-C Ctrl-l]= already is supported. You will only get suggestions for attachments if there are any attachments on the outline node you're in. Or in any of its parents if inheritance is configured. Regards Gustav From: Emacs-orgmode on behalf of stardiviner Sent: Thursday, December 12, 2019 6:21:30 AM To: emacs-orgmode@gnu.org Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options Hi Gustav, I suggest to add support for =[Ctrl-C Ctrl-l]= like ~file:~ link type. which will auto in completion list. It will be convenient for user. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, I suggest to add support for =[Ctrl-C Ctrl-l]= like ~file:~ link type. which will auto in completion list. It will be convenient for user. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Feng Shu, > -Original Message- > From: Feng Shu > Sent: den 4 januari 2019 13:22 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > I like this feature very much! I'm glad! I've just now sent an updated patch to the mailing-list. It contains quite substantial changes. Maybe you care to review it as well? Best Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi again! > -Original Message- > From: Ihor Radchenko > Sent: den 14 december 2018 03:16 > To: Gustav Wikström > Cc: emacs-orgmode > Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options > > > No, that's not what I want. What I'm talking about is extending org-mode > > conceptually > > with the concept of 0-level headlines, where the body of that "headline" > > would be > > everything before the first headline in a file, and where I could specify > > (for example) an > > attachment-directory and be able to use it with this new syntax to link to > > attached files. > > I guess I took it a bit far with the example of visualizing multiple files > > from a folder > > as separate headlines inside a single emacs-buffer though. It would be cool > > to be able to > > do that but my intention was more about introducing the 0-level headline > > concept. > > Yeah. But someone needs to volunteer with the patch. I just wanted to say I'm working on this. More info will come in a separate thread soon! Kind regards, Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Gustav Wikström writes: I like this feature very much! > Hi, > > > > I’ve attached a patch with some suggested additions to org-attach. Patch > comments below. Please review. > > > > Kind regards > > Gustav > > ___ > > Patch comments: > > * Add new linktype "attached" for attachments > > > > A new linktype "attached" is added in order to reduce link-duplication > > when wanting to link to files in attached folders of nodes. This works > > for both ID-based attachments and ATTACH_DIR. Inline images will > > trigger also for attachments, as well as search-decorations in the > > links. The goal is to make the functionality for attached-links > > mirror file-links. > > > > * Add further options for ATTACH_DIR > > > > When working with ATTACH_DIR there are now a couple of new options available: > > - org-attach-dir-inherit-by-default > > - org-attach-dir-create-if-not-exist > > - org-attach-dir-relative > > > > Descriptions of them can be found in the commit for each new customization. > > > > * Documentation in org-manual > > > > Org-manual is updated with the new link-type as well as some minor > > cleanup in the documentation related to external links and attachments. > --
Re: [O] FW: [RFC] Link-type for attachments, more attach options
> No, it's not there. I know of the custom agendas and use it currently. But I
> cannot anywhere specify more than one org-agenda-files parameter, for
> example.
I just tried:
#+begin_src emacs-lisp
(setq org-agenda-custom-commands
(quote (("v" "Test" tags-todo nil
((org-agenda-files '("~/Org/inbox.org"
("w" "Test 2" tags-todo nil
((org-agenda-files
'("~/Knowledge_base/2016/Private/Get_started_with_org_mode/get_started_org_mode.org")))
#+end_src
It works fine for me.
> No, that's not what I want. What I'm talking about is extending org-mode
> conceptually with the concept of 0-level headlines, where the body of that
> "headline" would be everything before the first headline in a file, and where
> I could specify (for example) an attachment-directory and be able to use it
> with this new syntax to link to attached files. I guess I took it a bit far
> with the example of visualizing multiple files from a folder as separate
> headlines inside a single emacs-buffer though. It would be cool to be able to
> do that but my intention was more about introducing the 0-level headline
> concept.
Yeah. But someone needs to volunteer with the patch.
It would be even better if these 0-level headings can be edited from the
referencing file.
Regards,
Ihor
Gustav Wikström writes:
> Hi,
>
>> -Original Message-
>> From: Ihor Radchenko
>> Sent: den 20 november 2018 15:01
>> To: Gustav Wikström
>> Cc: emacs-orgmode
>> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options
>>
>> Hi,
>>
>> >Generalize org-agenda by allowing us to have multiple ones, and make
>> them more general by thinking of them as a set of views that works on sets
>> of files. Maybe this is not for all, but I would appreciate to create
>> multiple "agendas" (even though I'd call them "libraries" in instead), and
>> possibly also an aggregate agenda consisting of other agendas.
>>
>> Isn't this already in org? You can use custom agendas with multiple
>> "agendas" (custom commands) and set the files they operate on with org-
>> agenda-files within custom commands.
>
> No, it's not there. I know of the custom agendas and use it currently. But I
> cannot anywhere specify more than one org-agenda-files parameter, for
> example.
>
>>
>> >If two org-mode files exist in the same folder with different names, it
>> would be awesome to think of (and work with) them as two top-level headings
>> inside one org-mode buffer. Similar to two level-1 headings inside an org-
>> mode file. For this to work all properties we can define for regular
>> headings should be possible to define for these "level-0 headings". For
>> example an attachment-folder or ID, a deadline, scheduled date, or TODO-
>> keyword should in that case be configurable on the whole file. I guess some
>> new conventions regarding syntax and existing properties would have to be
>> created as well.
>>
>> You can do something like below. It is pretty much what you want, except I
>> am not sure how to update the headings from local org files. Current org
>> version does not allow `:results replace` on raw org output.
>>
>> * Main heading
>>
>> #+name: org-files-here
>> #+begin_src bash
>> ls *.org
>> #+end_src
>>
>> #+begin_src emacs-lisp :var files=org-files-here() :var stars=(make-string
>> (car (org-heading-components)) ?*) :results raw replace drawer (let ((files
>> (mapcar #'car files)))
>> (cl-loop for file in files
>> concat (with-current-buffer (find-file-noselect file)
>> (concat (format "* %s\n" (buffer-file-name))
>> (replace-regexp-in-string "^\\*" (concat "*" stars)
>> (buffer-string)) #+end_src
>
> No, that's not what I want. What I'm talking about is extending org-mode
> conceptually with the concept of 0-level headlines, where the body of that
> "headline" would be everything before the first headline in a file, and where
> I could specify (for example) an attachment-directory and be able to use it
> with this new syntax to link to attached files. I guess I took it a bit far
> with the example of visualizing multiple files from a folder as separate
> headlines inside a single emacs-buffer though. It would be cool to be able to
> do that but my intention was more about introducing the 0-level headline
> concept.
>
> Thanks for your idea and suggestion though!
>
>>
>> Best,
>> Ihor
>
> Kind Regards,
> Gustav
>
signature.asc
Description: PGP signature
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: Ihor Radchenko > Sent: den 20 november 2018 15:01 > To: Gustav Wikström > Cc: emacs-orgmode > Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options > > Hi, > > >Generalize org-agenda by allowing us to have multiple ones, and make > them more general by thinking of them as a set of views that works on sets > of files. Maybe this is not for all, but I would appreciate to create > multiple "agendas" (even though I'd call them "libraries" in instead), and > possibly also an aggregate agenda consisting of other agendas. > > Isn't this already in org? You can use custom agendas with multiple > "agendas" (custom commands) and set the files they operate on with org- > agenda-files within custom commands. No, it's not there. I know of the custom agendas and use it currently. But I cannot anywhere specify more than one org-agenda-files parameter, for example. > > >If two org-mode files exist in the same folder with different names, it > would be awesome to think of (and work with) them as two top-level headings > inside one org-mode buffer. Similar to two level-1 headings inside an org- > mode file. For this to work all properties we can define for regular > headings should be possible to define for these "level-0 headings". For > example an attachment-folder or ID, a deadline, scheduled date, or TODO- > keyword should in that case be configurable on the whole file. I guess some > new conventions regarding syntax and existing properties would have to be > created as well. > > You can do something like below. It is pretty much what you want, except I > am not sure how to update the headings from local org files. Current org > version does not allow `:results replace` on raw org output. > > * Main heading > > #+name: org-files-here > #+begin_src bash > ls *.org > #+end_src > > #+begin_src emacs-lisp :var files=org-files-here() :var stars=(make-string > (car (org-heading-components)) ?*) :results raw replace drawer (let ((files > (mapcar #'car files))) > (cl-loop for file in files > concat (with-current-buffer (find-file-noselect file) > (concat (format "* %s\n" (buffer-file-name)) > (replace-regexp-in-string "^\\*" (concat "*" stars) > (buffer-string)) #+end_src No, that's not what I want. What I'm talking about is extending org-mode conceptually with the concept of 0-level headlines, where the body of that "headline" would be everything before the first headline in a file, and where I could specify (for example) an attachment-directory and be able to use it with this new syntax to link to attached files. I guess I took it a bit far with the example of visualizing multiple files from a folder as separate headlines inside a single emacs-buffer though. It would be cool to be able to do that but my intention was more about introducing the 0-level headline concept. Thanks for your idea and suggestion though! > > Best, > Ihor Kind Regards, Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, >Generalize org-agenda by allowing us to have multiple ones, and make them > more general by thinking of them as a set of views that works on sets of > files. Maybe this is not for all, but I would appreciate to create multiple > "agendas" (even though I'd call them "libraries" in instead), and possibly > also an aggregate agenda consisting of other agendas. Isn't this already in org? You can use custom agendas with multiple "agendas" (custom commands) and set the files they operate on with org-agenda-files within custom commands. >If two org-mode files exist in the same folder with different names, it > would be awesome to think of (and work with) them as two top-level headings > inside one org-mode buffer. Similar to two level-1 headings inside an > org-mode file. For this to work all properties we can define for regular > headings should be possible to define for these "level-0 headings". For > example an attachment-folder or ID, a deadline, scheduled date, or > TODO-keyword should in that case be configurable on the whole file. I guess > some new conventions regarding syntax and existing properties would have to > be created as well. You can do something like below. It is pretty much what you want, except I am not sure how to update the headings from local org files. Current org version does not allow `:results replace` on raw org output. * Main heading #+name: org-files-here #+begin_src bash ls *.org #+end_src #+begin_src emacs-lisp :var files=org-files-here() :var stars=(make-string (car (org-heading-components)) ?*) :results raw replace drawer (let ((files (mapcar #'car files))) (cl-loop for file in files concat (with-current-buffer (find-file-noselect file) (concat (format "* %s\n" (buffer-file-name)) (replace-regexp-in-string "^\\*" (concat "*" stars) (buffer-string)) #+end_src Best, Ihor Gustav Wikström writes: > Hi, > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 18 november 2018 01:42 >> To: Gustav Wikström ; Marco Wahl >> >> Cc: emacs-orgmode >> Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options >> >> Hi Gustav, >> >> > I like the idea of a function that would symbolically links folders >> > from "ID"-folder structure to a hierarchy-folder structure, based on >> > the name and path of the org-file and its headings containing the >> > links. I probably wouldn't use it much myself though. Not until >> > org-mode starts working better with multiple files, allowing us to >> > more easily define "org-mode libraries". >> >> I am wondering what you mean by "org-mode libraries". Can you explain >> further? > > This goes a bit off topic; But what I mean is mainly two things: > 1) Generalize the org-agenda so that we can have multiple ones > >Generalize org-agenda by allowing us to have multiple ones, and make them > more general by thinking of them as a set of views that works on sets of > files. Maybe this is not for all, but I would appreciate to create multiple > "agendas" (even though I'd call them "libraries" in instead), and possibly > also an aggregate agenda consisting of other agendas. > > 2) Make files function as virtual "level-0 headings" > >If two org-mode files exist in the same folder with different names, it > would be awesome to think of (and work with) them as two top-level headings > inside one org-mode buffer. Similar to two level-1 headings inside an > org-mode file. For this to work all properties we can define for regular > headings should be possible to define for these "level-0 headings". For > example an attachment-folder or ID, a deadline, scheduled date, or > TODO-keyword should in that case be configurable on the whole file. I guess > some new conventions regarding syntax and existing properties would have to > be created as well. > >> >> Also, another thought about the attachment: links. >> It would be useful to implement links to attachments, which are not in the >> current org entry. >> For example, something like "attachment:ORG-ID:file-name", where ORG-ID >> refers to ID of an arbitrary org entry. > > I wouldn't call that attachment-links, but rather ID-based links (since > attachments are local based on either headline ID or attach-dir of the > current headline). ID links exist already but link to headlines. > > If you rather see ID-based attachments as some kind of global attachments for > all your org-mode files, I'd think the link-type should reflect that and be > called something like "ID-attachment:file-name", "ID-@:file-name", > "@ID:file-name" and be a separate link-type. > >> >> Best, >> Ihor >> >> > > Kind regards > Gustav signature.asc Description: PGP signature
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: Ihor Radchenko > Sent: den 18 november 2018 01:42 > To: Gustav Wikström ; Marco Wahl > > Cc: emacs-orgmode > Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options > > Hi Gustav, > > > I like the idea of a function that would symbolically links folders > > from "ID"-folder structure to a hierarchy-folder structure, based on > > the name and path of the org-file and its headings containing the > > links. I probably wouldn't use it much myself though. Not until > > org-mode starts working better with multiple files, allowing us to > > more easily define "org-mode libraries". > > I am wondering what you mean by "org-mode libraries". Can you explain > further? This goes a bit off topic; But what I mean is mainly two things: 1) Generalize the org-agenda so that we can have multiple ones Generalize org-agenda by allowing us to have multiple ones, and make them more general by thinking of them as a set of views that works on sets of files. Maybe this is not for all, but I would appreciate to create multiple "agendas" (even though I'd call them "libraries" in instead), and possibly also an aggregate agenda consisting of other agendas. 2) Make files function as virtual "level-0 headings" If two org-mode files exist in the same folder with different names, it would be awesome to think of (and work with) them as two top-level headings inside one org-mode buffer. Similar to two level-1 headings inside an org-mode file. For this to work all properties we can define for regular headings should be possible to define for these "level-0 headings". For example an attachment-folder or ID, a deadline, scheduled date, or TODO-keyword should in that case be configurable on the whole file. I guess some new conventions regarding syntax and existing properties would have to be created as well. > > Also, another thought about the attachment: links. > It would be useful to implement links to attachments, which are not in the > current org entry. > For example, something like "attachment:ORG-ID:file-name", where ORG-ID > refers to ID of an arbitrary org entry. I wouldn't call that attachment-links, but rather ID-based links (since attachments are local based on either headline ID or attach-dir of the current headline). ID links exist already but link to headlines. If you rather see ID-based attachments as some kind of global attachments for all your org-mode files, I'd think the link-type should reflect that and be called something like "ID-attachment:file-name", "ID-@:file-name", "@ID:file-name" and be a separate link-type. > > Best, > Ihor > > Kind regards Gustav
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, > I'm not sure I follow your suggestion regarding changing the > implementation. But anyhow I don't think the implementation is heavy > and at risk of cumbersome code duplication. My opinion ofc Sure. The code is not that complicated. > I like the idea of a function that would symbolically links folders > from "ID"-folder structure to a hierarchy-folder structure, based on > the name and path of the org-file and its headings containing the > links. I probably wouldn't use it much myself though. Not until > org-mode starts working better with multiple files, allowing us to > more easily define "org-mode libraries". I am wondering what you mean by "org-mode libraries". Can you explain further? Also, another thought about the attachment: links. It would be useful to implement links to attachments, which are not in the current org entry. For example, something like "attachment:ORG-ID:file-name", where ORG-ID refers to ID of an arbitrary org entry. Best, Ihor Gustav Wikström writes: > Hi Ihor, > > I'm not sure I follow your suggestion regarding changing the implementation. > But anyhow I don't think the implementation is heavy and at risk of > cumbersome code duplication. My opinion ofc > > I like the idea of a function that would symbolically links folders from > "ID"-folder structure to a hierarchy-folder structure, based on the name and > path of the org-file and its headings containing the links. I probably > wouldn't use it much myself though. Not until org-mode starts working better > with multiple files, allowing us to more easily define "org-mode libraries". > > /G > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 3 november 2018 04:38 >> To: Gustav Wikström ; Marco Wahl >> Cc: emacs-orgmode >> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options >> >> Hi Gustav, >> >> Thanks for the patch! >> I am a heavy user of org attachments, so it is pleasant that someone >> spent a time to implement this useful feature into org. >> >> A comment regarding the code. >> Your new link types appears to reimplement some of the code for the >> "file:" links. >> Would it make more sense to implement the "attachment:" link type as >> abbreviation? >> I mean something like the code below: >> >> >> (defun yant/process-att-abbrev (arg) >> "Return `org-attach-dir' for the current entry." >> (s-concat (org-attach-dir 'CREATE) arg)) >> >> (add-to-list 'org-link-abbrev-alist (cons "att" >> "file:%(yant/process-att-abbrev)")) >> >> (defun org-att-link-complete ( arg) >> "Completion function for att: link." >> (let* ((ref-dir (org-attach-dir 'CREATE)) >> (filelink (let ((default-directory ref-dir)) >> (org-file-complete-link))) >> (filepath (apply #'s-concat (cdr (s-split ":" filelink) >> (format "att:%s" filepath))) >> >> (org-link-set-parameters "att" >> :complete #'org-att-link-complete) >> >> >> Also, is anyone interested in automatic placing of org attachments into >> a folder structure, which mirrors the org path? >> Something like in the following Stack Exchange question: >> https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org- >> attach >> >> Best, >> Ihor >> >> Gustav Wikström writes: >> >> > Hi Marco, >> > >> > Nice to hear you like it! Yeah, I'm pretty happy with that functionality >> > as well. Use it >> all the time to quickly add links to attached files. >> > >> > One use case I have for this (as an example) is for projects and tasks. I >> > have a >> 'tasks.org' file with nodes for each of my tasks and each of my projects. >> Usually, if the >> task is about some digital work, there are files involved with it. So I have >> a convention >> to add folders next to the 'tasks.org' file with names like 'YYMM >> [task/project title]', >> and attach the folder to each task/project node. C-c C-l attached RET then >> makes it super- >> easy to refer to particular files within that folder, from within the node >> in the >> 'tasks.org' file! >> > >> > Another use case is for my 'digital brain', where it's also fairly common >> > for me to have >> attachment folders where I want to refer to files within them. Images for >&
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Ihor, I'm not sure I follow your suggestion regarding changing the implementation. But anyhow I don't think the implementation is heavy and at risk of cumbersome code duplication. My opinion ofc I like the idea of a function that would symbolically links folders from "ID"-folder structure to a hierarchy-folder structure, based on the name and path of the org-file and its headings containing the links. I probably wouldn't use it much myself though. Not until org-mode starts working better with multiple files, allowing us to more easily define "org-mode libraries". /G > -Original Message- > From: Ihor Radchenko > Sent: den 3 november 2018 04:38 > To: Gustav Wikström ; Marco Wahl > Cc: emacs-orgmode > Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options > > Hi Gustav, > > Thanks for the patch! > I am a heavy user of org attachments, so it is pleasant that someone > spent a time to implement this useful feature into org. > > A comment regarding the code. > Your new link types appears to reimplement some of the code for the > "file:" links. > Would it make more sense to implement the "attachment:" link type as > abbreviation? > I mean something like the code below: > > > (defun yant/process-att-abbrev (arg) > "Return `org-attach-dir' for the current entry." > (s-concat (org-attach-dir 'CREATE) arg)) > > (add-to-list 'org-link-abbrev-alist (cons "att" > "file:%(yant/process-att-abbrev)")) > > (defun org-att-link-complete ( arg) > "Completion function for att: link." > (let* ((ref-dir (org-attach-dir 'CREATE)) >(filelink (let ((default-directory ref-dir)) >(org-file-complete-link))) >(filepath (apply #'s-concat (cdr (s-split ":" filelink) > (format "att:%s" filepath))) > > (org-link-set-parameters "att" >:complete #'org-att-link-complete) > > > Also, is anyone interested in automatic placing of org attachments into > a folder structure, which mirrors the org path? > Something like in the following Stack Exchange question: > https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org- > attach > > Best, > Ihor > > Gustav Wikström writes: > > > Hi Marco, > > > > Nice to hear you like it! Yeah, I'm pretty happy with that functionality as > > well. Use it > all the time to quickly add links to attached files. > > > > One use case I have for this (as an example) is for projects and tasks. I > > have a > 'tasks.org' file with nodes for each of my tasks and each of my projects. > Usually, if the > task is about some digital work, there are files involved with it. So I have > a convention > to add folders next to the 'tasks.org' file with names like 'YYMM > [task/project title]', > and attach the folder to each task/project node. C-c C-l attached RET then > makes it super- > easy to refer to particular files within that folder, from within the node in > the > 'tasks.org' file! > > > > Another use case is for my 'digital brain', where it's also fairly common > > for me to have > attachment folders where I want to refer to files within them. Images for > example, that > then will be displayed in the org-mode file. Haven't settled on whether I > should use auto- > managed ID's for these folders, or :ATTACH_DIR: properties though. Currently > using a bit > of both... > > > > I'm not familiar with the 'next' branch and the plans for integrating it > > into 'master'. > But if 'master' is to offensive to merge into straight away, 'next' sounds > like a good > option! > > > > Kind regards > > Gustav > > > > -Original Message- > > From: Marco Wahl > > Sent: den 1 november 2018 17:01 > > To: Gustav Wikström > > Subject: Re: FW: [RFC] Link-type for attachments, more attach options > > > > The following message is a courtesy copy of an article that has been posted > > to > gmane.emacs.orgmode as well. > > > > Hi Gustav, > > > > I played a bit with your proposition. I like it; in particular the > > completion function > to insert links from the attachment directory with > > > > C-c C-l attached RET > > > > It seems natural to me to have a more specific link type for attached files. > > > > In my opinion your patch should be applied to the 'next' branch. > > > > > > My 2ct, > > Marco > >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Nicolas, Thanks for your detailed comments. Much appreciated. > -Original Message- > From: Nicolas Goaziou > Sent: den 4 november 2018 23:37 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: FW: [RFC] Link-type for attachments, more attach options > > Hello, > > Gustav Wikström writes: > > > I’ve attached a patch with some suggested additions to org-attach. > > Patch comments below. Please review. > > Thank you. Some comments follow. > > > * Add new linktype "attached" for attachments > > This seem a bit long. Why not "att" links? Yeah - I liked "attached" because I prefer clear keywords. But sure, we can keep it shorter. I'd suggest "@" instead in that case. Patch updated with that. > > > * Add further options for ATTACH_DIR > > > > When working with ATTACH_DIR there are now a couple of new options > > available: > > - org-attach-dir-inherit-by-default > > What is the difference between this and `org-attach-allow-inheritance'? > > > - org-attach-dir-create-if-not-exist > > What is the use-case for this one? It doesn't seem terribly useful at > first glance. If you try to open attachments on a node where there is no ID or ATTACH_DIR, the default behavior is to add an ID and create a folder based on that ID. I would like Org-mode to not do that. This customization give the user the option to change that. Instead of providing this customization one could just change the default behavior of org-attach, since it's a bit offensive to create folders when I didn't ask for it. But instead of changing the default, I thought this way was more graceful. I wouldn't mind skipping this customization though, if the behavior was changed to what I implemented with org-attach-dir-create-if-not-exist set to nil. > > > - org-attach-dir-relative > > I'm not sure to understand this one. When adding folders to nodes using option "s" in org-attach, the path is absolute. This makes attachment-directory paths relative to location of the file instead. > > > > +This list shows the full set of built-in external link types: > > +| http | web | > > +| https | secure web | > > +| doi| DOI for electronic resources| > > +| file | file-links | > > +| file+sys | file-links forced to open via OS| > > +| file+emacs | file-links forced to open via emacs | > > +| attached | links to attachments for nodes | > > +| docview| doc-view mode | > > +| id | Link to heading by id | > > +| news | Usenet link | > > +| mailto | mail link | > > +| mhe| MH-E folder link| > > +| rmail | Rmail link | > > +| gnus | Gnus link | > > +| bbdb | BBDB link | > > +| irc| IRC link| > > +| info | Info link | > > +| shell | shell command | > > +| elisp | interactive elisp command link | > > + > > +The following list shows examples for each link type. > > + > > +| =http://www.astro.uva.nl/=dominik=| on the web > >| > > +| =doi:10.1000/182= | DOI for an electronic > > resource | > > +| =file:/home/dominik/images/jupiter.jpg= | file, absolute path > >| > > +| =/home/dominik/images/jupiter.jpg=| same as above > >| > > +| =file:papers/last.pdf=| file, relative path > >| > > +| =./papers/last.pdf= | same as above > >| > > +| =file:/ssh:me@some.where:papers/last.pdf= | file, path on remote machine > >| > > +| =/ssh:me@some.where:papers/last.pdf= | same as above > >| > > +| =file:sometextfile::NNN= | file, jump to line number > >| > > +| =file:projects.org= | another Org file > >| > > +| =file:projects.org::some words= | text search in Org > > file[fn:28] | > > +| =file:projects.org::*task title= | heading search in Org file > >| > > +| =file+sys:/path/to/file= | open via OS, like > > double-click | > > +| =file+emacs:/path/to/file=| force opening by Emacs > >| > > +| =attached:projects.org= | file in folder attached to > > headline | > > +| =attached:projects.org::some words= | text search in attached file > >| > > +| =docview:papers/last.pdf::NNN=| open in doc-view mode at > > page | > > +| =id:B7423F4D-2E8A-471B-8810-C40F074717E9= | link to heading by ID > >| > > +| =news:comp.emacs=
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hello, Gustav Wikström writes: > I’ve attached a patch with some suggested additions to org-attach. > Patch comments below. Please review. Thank you. Some comments follow. > * Add new linktype "attached" for attachments This seem a bit long. Why not "att" links? > * Add further options for ATTACH_DIR > > When working with ATTACH_DIR there are now a couple of new options available: > - org-attach-dir-inherit-by-default What is the difference between this and `org-attach-allow-inheritance'? > - org-attach-dir-create-if-not-exist What is the use-case for this one? It doesn't seem terribly useful at first glance. > - org-attach-dir-relative I'm not sure to understand this one. > > +This list shows the full set of built-in external link types: > +| http | web | > +| https | secure web | > +| doi| DOI for electronic resources| > +| file | file-links | > +| file+sys | file-links forced to open via OS| > +| file+emacs | file-links forced to open via emacs | > +| attached | links to attachments for nodes | > +| docview| doc-view mode | > +| id | Link to heading by id | > +| news | Usenet link | > +| mailto | mail link | > +| mhe| MH-E folder link| > +| rmail | Rmail link | > +| gnus | Gnus link | > +| bbdb | BBDB link | > +| irc| IRC link| > +| info | Info link | > +| shell | shell command | > +| elisp | interactive elisp command link | > + > +The following list shows examples for each link type. > + > +| =http://www.astro.uva.nl/=dominik=| on the web > | > +| =doi:10.1000/182= | DOI for an electronic resource > | > +| =file:/home/dominik/images/jupiter.jpg= | file, absolute path > | > +| =/home/dominik/images/jupiter.jpg=| same as above > | > +| =file:papers/last.pdf=| file, relative path > | > +| =./papers/last.pdf= | same as above > | > +| =file:/ssh:me@some.where:papers/last.pdf= | file, path on remote machine > | > +| =/ssh:me@some.where:papers/last.pdf= | same as above > | > +| =file:sometextfile::NNN= | file, jump to line number > | > +| =file:projects.org= | another Org file > | > +| =file:projects.org::some words= | text search in Org file[fn:28] > | > +| =file:projects.org::*task title= | heading search in Org file > | > +| =file+sys:/path/to/file= | open via OS, like double-click > | > +| =file+emacs:/path/to/file=| force opening by Emacs > | > +| =attached:projects.org= | file in folder attached to > headline | > +| =attached:projects.org::some words= | text search in attached file > | > +| =docview:papers/last.pdf::NNN=| open in doc-view mode at page > | > +| =id:B7423F4D-2E8A-471B-8810-C40F074717E9= | link to heading by ID > | > +| =news:comp.emacs= | Usenet link > | > +| =mailto:ad...@galaxy.net= | mail link > | > +| =mhe:folder= | MH-E folder link > | > +| =mhe:folder#id= | MH-E message link > | > +| =rmail:folder=| Rmail folder link > | > +| =rmail:folder#id= | Rmail message link > | > +| =gnus:group= | Gnus group link > | > +| =gnus:group#id= | Gnus article link > | > +| =bbdb:R.*Stallman=| BBDB link (with regexp) > | > +| =irc:/irc.com/#emacs/bob= | IRC link > | > +| =info:org#External links= | Info node link > | > +| =shell:ls *.org= | shell command > | > +| =elisp:org-agenda=| interactive Elisp command > | > +| =elisp:(find-file "Elisp.org")= | Elisp form to evaluate > | I'm not sure to like the change above. It introduces a lot of redundancy. > Here is the syntax of the different ways to attach a search to a file > link, together with explanations for each: > > #+begin_example >
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, Thanks for the patch! I am a heavy user of org attachments, so it is pleasant that someone spent a time to implement this useful feature into org. A comment regarding the code. Your new link types appears to reimplement some of the code for the "file:" links. Would it make more sense to implement the "attachment:" link type as abbreviation? I mean something like the code below: (defun yant/process-att-abbrev (arg) "Return `org-attach-dir' for the current entry." (s-concat (org-attach-dir 'CREATE) arg)) (add-to-list 'org-link-abbrev-alist (cons "att" "file:%(yant/process-att-abbrev)")) (defun org-att-link-complete ( arg) "Completion function for att: link." (let* ((ref-dir (org-attach-dir 'CREATE)) (filelink (let ((default-directory ref-dir)) (org-file-complete-link))) (filepath (apply #'s-concat (cdr (s-split ":" filelink) (format "att:%s" filepath))) (org-link-set-parameters "att" :complete #'org-att-link-complete) Also, is anyone interested in automatic placing of org attachments into a folder structure, which mirrors the org path? Something like in the following Stack Exchange question: https://emacs.stackexchange.com/questions/26412/human-readable-directory-tree-with-org-attach Best, Ihor Gustav Wikström writes: > Hi Marco, > > Nice to hear you like it! Yeah, I'm pretty happy with that functionality as > well. Use it all the time to quickly add links to attached files. > > One use case I have for this (as an example) is for projects and tasks. I > have a 'tasks.org' file with nodes for each of my tasks and each of my > projects. Usually, if the task is about some digital work, there are files > involved with it. So I have a convention to add folders next to the > 'tasks.org' file with names like 'YYMM [task/project title]', and attach the > folder to each task/project node. C-c C-l attached RET then makes it > super-easy to refer to particular files within that folder, from within the > node in the 'tasks.org' file! > > Another use case is for my 'digital brain', where it's also fairly common for > me to have attachment folders where I want to refer to files within them. > Images for example, that then will be displayed in the org-mode file. Haven't > settled on whether I should use auto-managed ID's for these folders, or > :ATTACH_DIR: properties though. Currently using a bit of both... > > I'm not familiar with the 'next' branch and the plans for integrating it into > 'master'. But if 'master' is to offensive to merge into straight away, 'next' > sounds like a good option! > > Kind regards > Gustav > > -Original Message- > From: Marco Wahl > Sent: den 1 november 2018 17:01 > To: Gustav Wikström > Subject: Re: FW: [RFC] Link-type for attachments, more attach options > > The following message is a courtesy copy of an article that has been posted > to gmane.emacs.orgmode as well. > > Hi Gustav, > > I played a bit with your proposition. I like it; in particular the > completion function to insert links from the attachment directory with > > C-c C-l attached RET > > It seems natural to me to have a more specific link type for attached files. > > In my opinion your patch should be applied to the 'next' branch. > > > My 2ct, > Marco > signature.asc Description: PGP signature
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Marco, Nice to hear you like it! Yeah, I'm pretty happy with that functionality as well. Use it all the time to quickly add links to attached files. One use case I have for this (as an example) is for projects and tasks. I have a 'tasks.org' file with nodes for each of my tasks and each of my projects. Usually, if the task is about some digital work, there are files involved with it. So I have a convention to add folders next to the 'tasks.org' file with names like 'YYMM [task/project title]', and attach the folder to each task/project node. C-c C-l attached RET then makes it super-easy to refer to particular files within that folder, from within the node in the 'tasks.org' file! Another use case is for my 'digital brain', where it's also fairly common for me to have attachment folders where I want to refer to files within them. Images for example, that then will be displayed in the org-mode file. Haven't settled on whether I should use auto-managed ID's for these folders, or :ATTACH_DIR: properties though. Currently using a bit of both... I'm not familiar with the 'next' branch and the plans for integrating it into 'master'. But if 'master' is to offensive to merge into straight away, 'next' sounds like a good option! Kind regards Gustav -Original Message- From: Marco Wahl Sent: den 1 november 2018 17:01 To: Gustav Wikström Subject: Re: FW: [RFC] Link-type for attachments, more attach options The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Hi Gustav, I played a bit with your proposition. I like it; in particular the completion function to insert links from the attachment directory with C-c C-l attached RET It seems natural to me to have a more specific link type for attached files. In my opinion your patch should be applied to the 'next' branch. My 2ct, Marco
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, nice to hear that you find it useful! I don’t have access to apply the patch myself. So I’d be happy if one of the frequent maintainers could help out with that, and at the same time look a bit at the quality of it. I’ve used most of the functionality personally for well over a year in my local setup and just now took the time to repackage it into something reusable. Hopefully it’s seen as “good enough” to warrant a merge into one of the org-mode branches! From my perspective the patch adds a lot of utility to the attachment-functionality. Regards Gustav From: tumashu Sent: den 1 november 2018 02:46 To: Gustav Wikström Cc: emacs-orgmode Subject: Re:[O] FW: [RFC] Link-type for attachments, more attach options Hello, this feature seem to be very useful, what is this patch status? At 2018-10-21 15:53:38, "Gustav Wikström" mailto:gus...@whil.se>> wrote: Hi, I’ve attached a patch with some suggested additions to org-attach. Patch comments below. Please review. Kind regards Gustav ___ Patch comments: * Add new linktype "attached" for attachments A new linktype "attached" is added in order to reduce link-duplication when wanting to link to files in attached folders of nodes. This works for both ID-based attachments and ATTACH_DIR. Inline images will trigger also for attachments, as well as search-decorations in the links. The goal is to make the functionality for attached-links mirror file-links. * Add further options for ATTACH_DIR When working with ATTACH_DIR there are now a couple of new options available: - org-attach-dir-inherit-by-default - org-attach-dir-create-if-not-exist - org-attach-dir-relative Descriptions of them can be found in the commit for each new customization. * Documentation in org-manual Org-manual is updated with the new link-type as well as some minor cleanup in the documentation related to external links and attachments.
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi Gustav, I played a bit with your proposition. I like it; in particular the completion function to insert links from the attachment directory with C-c C-l attached RET It seems natural to me to have a more specific link type for attached files. In my opinion your patch should be applied to the 'next' branch. My 2ct, Marco
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hello, this feature seem to be very useful, what is this patch status? At 2018-10-21 15:53:38, "Gustav Wikström" wrote: Hi, I’ve attached a patch with some suggested additions to org-attach. Patch comments below. Please review. Kind regards Gustav ___ Patch comments: * Add new linktype "attached" for attachments A new linktype "attached" is added in order to reduce link-duplication when wanting to link to files in attached folders of nodes. This works for both ID-based attachments and ATTACH_DIR. Inline images will trigger also for attachments, as well as search-decorations in the links. The goal is to make the functionality for attached-links mirror file-links. * Add further options for ATTACH_DIR When working with ATTACH_DIR there are now a couple of new options available: - org-attach-dir-inherit-by-default - org-attach-dir-create-if-not-exist - org-attach-dir-relative Descriptions of them can be found in the commit for each new customization. * Documentation in org-manual Org-manual is updated with the new link-type as well as some minor cleanup in the documentation related to external links and attachments.
[O] FW: [RFC] Link-type for attachments, more attach options
Hi, I’ve attached a patch with some suggested additions to org-attach. Patch comments below. Please review. Kind regards Gustav ___ Patch comments: * Add new linktype "attached" for attachments A new linktype "attached" is added in order to reduce link-duplication when wanting to link to files in attached folders of nodes. This works for both ID-based attachments and ATTACH_DIR. Inline images will trigger also for attachments, as well as search-decorations in the links. The goal is to make the functionality for attached-links mirror file-links. * Add further options for ATTACH_DIR When working with ATTACH_DIR there are now a couple of new options available: - org-attach-dir-inherit-by-default - org-attach-dir-create-if-not-exist - org-attach-dir-relative Descriptions of them can be found in the commit for each new customization. * Documentation in org-manual Org-manual is updated with the new link-type as well as some minor cleanup in the documentation related to external links and attachments. 0001-org-attach-org-manual-org-New-link-type-more-attach-.patch Description: 0001-org-attach-org-manual-org-New-link-type-more-attach-.patch
