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

2020-01-19 Thread Gustav Wikström
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

2020-01-18 Thread stardiviner
 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

2020-01-18 Thread Gustav Wikström
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

2020-01-18 Thread stardiviner

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

2020-01-16 Thread stardiviner


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

2020-01-15 Thread Gustav Wikström
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

2020-01-14 Thread stardiviner


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

2020-01-14 Thread Gustav Wikström
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

2020-01-13 Thread stardiviner


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

2019-12-16 Thread stardiviner


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

2019-12-16 Thread stardiviner


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

2019-12-15 Thread stardiviner


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

2019-12-15 Thread Gustav Wikström
> -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

2019-12-15 Thread stardiviner


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

2019-12-15 Thread Gustav Wikström
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

2019-12-15 Thread stardiviner


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

2019-12-14 Thread stardiviner


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

2019-12-13 Thread Gustav Wikström
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

2019-12-13 Thread Gustav Wikström
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

2019-12-13 Thread stardiviner


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

2019-12-12 Thread Gustav Wikström
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

2019-12-12 Thread stardiviner


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

2019-12-11 Thread Gustav Wikström
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

2019-12-11 Thread stardiviner


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

2019-05-26 Thread Gustav Wikström
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

2019-05-26 Thread Gustav Wikström
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

2019-01-04 Thread Feng Shu
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

2018-12-13 Thread Ihor Radchenko
> 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

2018-11-24 Thread Gustav Wikström
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

2018-11-20 Thread Ihor Radchenko
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

2018-11-18 Thread Gustav Wikström
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

2018-11-17 Thread Ihor Radchenko
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

2018-11-17 Thread Gustav Wikström
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

2018-11-17 Thread Gustav Wikström
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

2018-11-04 Thread Nicolas Goaziou
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

2018-11-02 Thread Ihor Radchenko
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

2018-11-02 Thread Gustav Wikström
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

2018-11-02 Thread Gustav Wikström
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

2018-11-01 Thread Marco Wahl
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

2018-10-31 Thread tumashu
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.