Missing `org-attach-set-inherit' function
I found the function ~org-attach-set-inherit~ is missing. I noticed it in the Info document. #+begin_quote ‘i’ (‘org-attach-set-inherit’) Set the ‘ATTACH_DIR_INHERIT’ property, so that children use the same directory for attachments as the parent does. #+end_quote -- [ 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
[bug] org-agenda-sorting-strategy sorting incorrectly?
With the following: (setq org-agenda-sorting-strategy '((agenda time-up deadline-down scheduled-down habit-down priority-down category-keep) (todo priority-down category-keep) (tags priority-down category-keep) (search category-keep))) The `time-up` is correctly shown first; however, all scheduled items are shown next as opposed to all deadline items (the order should be the other way around). Also, it is unfortunate that there is no symbol for upcoming deadline items to differentiate them from past deadline items. Since they are considered "earliest", the sorting goes from "In 5 days... -> In 3 days... -> 2 days ago --> 4 days ago", which is rarely useful. There is no way to sort just items past due date "2 days ago --> 4 days ago --> 5 days ago", which is a much more common workflow (e.g. looking down the agenda, the more salvageable recent deadline items are at the top). It is more sensible to just limit deadline items to items due today or the past, and have a separate symbol for upcoming deadlines (i.e. "upcoming-deadline-down" and "upcoming-deadline-up"). Then, one can e.g. put all upcoming deadline items at the bottom of the agenda because he wants to deal with items that are more relevant now. Currently on lorg-mode 9.3.1 (latest version of org-mode available as of this submission).
Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > Hardcoding the translation of attachment-links into file-links in an > in-between layer (ox.el - that is somewhat complicated as well) is not > transparent and I think best to avoid. Even if an attachment link is > /very/ similar to a file link it may be best still to treat them for > what they are. If some export back-ends out in the wild don't work > with attachment-links today then so be it. But let's at least make it > easy to fix! So I'll try to remove the hard coding of org-attach > invocation and instead make the attachment-path when parsed by > org-element return a path that is an actual file-system path out of > the box. I'll see what I figure out in terms of code I suppose...! > > What do you say? It is true that Element library expands link abbreviations right before parsing a link, and an attachment is similar to a local link abbreviation. This is not great because some information is lost in the process: interpreting the parse tree will not bring the abbreviation back, only its expanded form. Actually, `org-link-expand-abbrev' is called so that the parser knows what is the true type of the link, since abbreviations could expand to anything. OTOH, attachments can only expand to a "file" link, so the motivation for expansion doesn't hold. Besides, there's no good reason to store redundant, or even remote, information in the parse tree. The parser needs to be as low level as possible. Moreover, the issue encountered here is specific to export, so it makes sense to solve at the export level, i.e., in "ox.el". This is not trivial though, as it needs to be done very early, much link footnotes. Indeed, since the meaning of the link is position dependent, including parts of a document, or executing arbitrary code can mess it up. IOW expansion should happen in `org-export--prepare-file-contents', i.e., within every included piece of text, and in `org-export-as', somewhere after `org-export-expand-include-keyword' call, but before Babel code execution. HTH, Regards,
RE: attachment: link type export to HTML invalid attach dir
Hi again, > -Original Message- > From: Gustav Wikström > Sent: den 16 januari 2020 22:42 > To: Nicolas Goaziou > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: RE: attachment: link type export to HTML invalid attach dir > > Hi Nicolas, > > > -Original Message- > > From: Nicolas Goaziou > > Sent: den 16 januari 2020 14:18 > > To: Gustav Wikström > > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > > Subject: Re: attachment: link type export to HTML invalid attach dir > > > > Hello, > > > > Gustav Wikström writes: > > > > > Ah yes. Found the culprit for this issue. Hopefully the last one. > > > The exporter doesn't actually move the point in the buffer during > > > the export. So org-attach-expand tried to expand from the first > > > character in the buffer. This should be fixed from a few minutes ago. > > > > I'm not sure hard-coding attachment links in exporters in the best way > > forward. For example, exporters in the wild may not cope with them > > before a long time, if ever. There is some code duplication, too. > > Yes indeed, duplicated functionality for all export backends as it stands. > > > > > If attachments links are similar to file links from an export point of > > view, then I suggest to add a phase in ox.el to expand the former into > > the latter, before even using export back-ends. This way, there is no > > change required in the exporters, shipped in or not. > > Yeah, I do think attachment links should be treated as file links when > exported. And I like this suggestion, although that means I probably have > to dig into the ox.el code. Not an easy task. I suspect you'd guide me to > adding logic inside org-export-as for this. I'll have a look starting from > there. But wouldn't mind some further insights here! After thinking a while I'm leaning towards thinking this should be handled already in the element link parser and interpreter. Need a bit more metadata for that though, to be able to deconstruct and reconstruct the link properly while still providing the correct paths. Hardcoding the translation of attachment-links into file-links in an in-between layer (ox.el - that is somewhat complicated as well) is not transparent and I think best to avoid. Even if an attachment link is /very/ similar to a file link it may be best still to treat them for what they are. If some export back-ends out in the wild don't work with attachment-links today then so be it. But let's at least make it easy to fix! So I'll try to remove the hard coding of org-attach invocation and instead make the attachment-path when parsed by org-element return a path that is an actual file-system path out of the box. I'll see what I figure out in terms of code I suppose...! What do you say? > > Regards > Gustav > > > > > Regards, > > > > -- > > Nicolas Goaziou
Bug: org-ellipsis does not work as a local variable [9.3.1 (release_9.3.1-95-gf93020 @ /home/mark/git-repos/org-mode/lisp/)]
The "org-ellipsis" variable is specifically marked as (potentially) a safe local variable, so obviously someone intended for it possibly to be used that, and believed that it might be useful to someone as a local variable. However, there is no setup that I can find which makes this work. Placing : # Local Variables: : # org-ellipsis: "XXX" : # End: at the end of the file, or setting it in the top line, makes no change in the ellipsis, even if you do M-x org-mode again or reload the file (with find-alternate-file). Indeed, M-x org-mode clears the local value assignment altogether. Setting it by hand with setq-local doesn't work (it is cleared when you do M-x org-mode again anyway, as mentioned.) So, is org-ellipsis really not meant ever to be a local variable? If so, that likely should be documented, and certainly the :safe annotation on it should be removed, as it strongly implies that using it as a local variable is acceptable and useful. I ran this with emacs -Q, using using the code from the git repository, commit f93020d5e6d7594c335cc129ad02c21ac26ed58a (as you can see by the local filepath below.) I hope I have explained the bug clearly enough. Thanks ~mark Emacs : GNU Emacs 26.3 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.13) of 2019-12-10 Package: Org mode version 9.3.1 (release_9.3.1-95-gf93020 @ /home/mark/git-repos/org-mode/lisp/) current state: == (setq org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-link-shell-confirm-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-reveal-start-hook '(org-decrypt-entry) org-mode-hook '((closure (org--rds reftex-docstruct-symbol org-element-greater-elements org-clock-history org-agenda-current-date org-with-time org-defdecode org-def org-read-date-inactive org-ans2 org-ans1 org-columns-current-fmt-compiled org-clock-current-task org-clock-effort org-agenda-skip-function org-agenda-skip-comment-trees org-agenda-archives-mode org-end-time-was-given org-time-was-given org-log-note-extra org-log-note-purpose org-log-post-message org-last-inserted-timestamp org-last-changed-timestamp org-entry-property-inherited-from org-blocked-by-checkboxes org-state org-agenda-headline-snapshot-before-repeat org-capture-last-stored-marker org-agenda-start-on-weekday org-agenda-buffer-tmp-name org-priority-regexp org-mode-syntax-table buffer-face-mode-face org-tbl-menu org-org-menu org-struct-menu org-entities org-last-state org-id-track-globally org-clock-start-time texmathp-why remember-data-file org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist calc-embedded-open-mode calc-embedded-open-formula calc-embedded-close-formula align-mode-rules-list org-emphasis-alist org-emphasis-regexp-components org-export-registered-backends org-modules org-babel-load-languages org-indent-indentation-per-level org-element-paragraph-separate ffap-url-regexp org-inlinetask-min-level t) nil (add-hook (quote change-major-mode-hook) (quote org-show-all) (quote append) (quote local)) ) (closure (org-src-window-setup *this* org-babel-confirm-evaluate-answer-no org-src-preserve-indentation org-src-lang-modes org-link-file-path-type org-edit-src-content-indentation org-babel-library-of-babel t) nil (add-hook (quote change-major-mode-hook) (quote org-babel-show-result-all) (quote append) (quote local)) ) org-babel-result-hide-spec org-babel-hide-all-hashes) org-archive-hook '(org-attach-archive-delete-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-agenda-before-write-hook '(org-agenda-add-entry-text) org-metaup-hook '(org-babel-load-in-session-maybe) org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn ENTRY)"] org-babel-pre-tangle-hook '(save-buffer) org-tab-first-hook '(org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-occur-hook '(org-first-headline-recenter) org-cycle-hook
RE: attachment: link type export to HTML invalid attach dir
Hi Nicolas, > -Original Message- > From: Nicolas Goaziou > Sent: den 16 januari 2020 14:18 > To: Gustav Wikström > Cc: numbch...@gmail.com; emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > Hello, > > Gustav Wikström writes: > > > Ah yes. Found the culprit for this issue. Hopefully the last one. The > > exporter doesn't actually move the point in the buffer during the > > export. So org-attach-expand tried to expand from the first character > > in the buffer. This should be fixed from a few minutes ago. > > I'm not sure hard-coding attachment links in exporters in the best way > forward. For example, exporters in the wild may not cope with them before > a long time, if ever. There is some code duplication, too. Yes indeed, duplicated functionality for all export backends as it stands. > > If attachments links are similar to file links from an export point of > view, then I suggest to add a phase in ox.el to expand the former into the > latter, before even using export back-ends. This way, there is no change > required in the exporters, shipped in or not. Yeah, I do think attachment links should be treated as file links when exported. And I like this suggestion, although that means I probably have to dig into the ox.el code. Not an easy task. I suspect you'd guide me to adding logic inside org-export-as for this. I'll have a look starting from there. But wouldn't mind some further insights here! Regards Gustav > > Regards, > > -- > Nicolas Goaziou
Bug? Multi day event with times
Hi! Stumbled upon this: ( emacs 26.3, org-contrib-plus 20191118, linux) In my orgfile I have: ** some travel <2020-01-30 Do 10:00>-<2020-02-01 Sa 16:00> In the agenda that is shown as: Donnerstag 30 January 2020 unsorted: 10:00-11:00 (1/3): some travel Freitag31 January 2020 unsorted: (2/3): some travel Samstag 1 February 2020 unsorted: 16:00-17:00 (3/3): some travel Not sure I want to call it a real bug as I can understand why it happens that way, but it's not what I expected. My travel starts at 10am on Thurday and stretches till Sunday 4pm. Any hint how to enter such an event besides splitting in three and losing the 2/3 information on Friday? Detlef
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > Ah yes. Found the culprit for this issue. Hopefully the last one. The > exporter doesn't actually move the point in the buffer during the > export. So org-attach-expand tried to expand from the first character > in the buffer. This should be fixed from a few minutes ago. I'm not sure hard-coding attachment links in exporters in the best way forward. For example, exporters in the wild may not cope with them before a long time, if ever. There is some code duplication, too. If attachments links are similar to file links from an export point of view, then I suggest to add a phase in ox.el to expand the former into the latter, before even using export back-ends. This way, there is no change required in the exporters, shipped in or not. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Gustav Wikström writes: > Hi, > >> -Original Message- >> From: stardiviner >> Sent: den 15 januari 2020 06:53 >> To: Gustav Wikström >> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org >> Subject: Re: attachment: link type export to HTML invalid attach dir >> >> [...] >> >> I checked out the latest commit "0ac6a9e1f", The ~~ tag is solved. >> But the ~(org-attach-dir)~ still not work. The exported ~~ >> inline image still does not contains the attach directory. > > Ah yes. Found the culprit for this issue. Hopefully the last one. The exporter doesn't actually move the point in the buffer during the export. So org-attach-expand tried to expand from the first character in the buffer. This should be fixed from a few minutes ago. Aha, wow!!! thanks for great patch. It worked now. Thanks really. :) > > Crossing fingers for this to work properly now! > > 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
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
