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