Re: [O] org-links for Gnus in imap with Gmail (for a convenient todo.org list)
Le sam. 27 juil. 2019 à 11:32:01 , Bob Newell a envoyé ce message: > Bonjour Josef, > > Je ne suis pas assez doué avec org-mode pour donner des conseils > expertes. Mais j'ai quand même une idée. Peut-être vous pouviez utiliser > 'advice' au lieu d'un 'hook' sur org-capture-finalize > > Par exemple (attention! pas verifié!) > > (defun jr/fix-the-link (&rest args) > (interactive) > (save-excursion >(find-file "~/Dropbox/Orgzly/links.org") >(goto-char (point-min)) >(while (search-forward "INBOX" nil t) > (replace-match "Tous les messages")) >(save-buffer))) > (advice-add 'org-capture-finalize :after #'jr/fix-the-link) > > Bonne chance ... ! Merci vivement Bob, c'est vraiment très gentil de me répondre et de le faire en français! I feel free now to speak in English and to cc. the email to the list, because it is interesting. If I understand the code above, Bob suggested to me to define a function that replace a definite string in a definite file just with saving it. I do not doubt that it is possible for an expert. Even if I am not desperate, it's like a message in a bottle thrown into the sea: can someone help me to do that? (It would be also possible to change the string at refiling, because the link in todo.org must be refiled to links.org) Best wishes, -- Joseph
Re: [O] CUSTOM_ID vs ID
Hello, Nathan Neff writes: > I've often been confused why org-mode has both a CUSTOM_ID > and a ID property. I mean, why not just use one or the other name? Custom ID are user-defined, and only meaningful in the scope of the document. Also, they may appear as-is when exported, e.g., as an anchor in HTML. ID are (or should be) generated by Org, and are valid across files, which means they need to be absolutely unique. Org keeps track of ID if `org-id-track-globally' is non-nil (the default). If this is nil, there is almost no difference between ID and custom ID. > When would I ever have both an ID and a CUSTOM_ID property for > a heading? You may want to refer to a heading from anywhere with id:... but need a clean anchor in HTML export, for example. FWIW, I never use ID property. Regards, -- Nicolas Goaziou
[O] export outside of emacs
Hi all, how can I run emacs to export org-mode files from outside of Emacs? I would like to provide a Makefile or a script to automatically build PDFs (LaTeX and Beamer) out of my org file repository. Thanks, Luca
Re: [O] export outside of emacs
On Sun, Jul 28, 2019, 6:28 AM Luca Ferrari wrote: > Hi all, > how can I run emacs to export org-mode files from outside of Emacs? You just run with --batch. That starts "emacs -Q" in batch mode. If you need to load some elisp at that point to make your export work, you can pack all that in an elisp file and pass that to the --eval switch. Finally use -f switch to specify which function to run to do the export. Here's one example[1] (look at the "emacs-batch" target in there. I would like to provide a Makefile or a script to automatically build > PDFs (LaTeX and Beamer) out of my org file repository. > [1]: https://github.com/kaushalmodi/ox-hugo/blob/master/Makefile >
[O] Bug: Saving and killing buffers with org-capture-refile and multiple agenda files [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi all,
I document here some behaviors of =org-capture-refile= which occur when
settings
involve multiple files as refile targets, with respect to saving and
killing
buffers. Most of them are designed to show some more integration
between
=org-capture= and =org-capture-refile= would be welcome, and one of them
actually
does not correspond to documented behavior.
Consider the following scenario. We have two agenda files, one for work,
another for personal tasks. They have the following content:
#+name: ~/org/home.org
#+begin_src org
,* Home tasks
,* Capture
#+end_src
#+name: ~/org/work.org
#+begin_src org
,* Work tasks
#+end_src
We start ~emacs -Q~, and do some basic setup:
#+begin_src emacs-lisp
(package-initialize)
(global-set-key (kbd "C-c c") 'org-capture)
(setq org-agenda-files
'("~/org/home.org"
"~/org/work.org"))
(setq org-refile-targets
'((org-agenda-files :maxlevel . 2)))
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/home.org" "Capture")
"* TODO %?"
:kill-buffer t)))
#+end_src
In particular, we are not setting the =:no-save= flag, so we expect the
default
behavior of buffers getting saved.
Now, we start a capture of an arbitrary task, and leave the capture
process by
refiling it to the heading =* Home tasks=.
If we then list-buffers ("C-x C-b"), we find that =home.org= has been
killed as
expected, given the template's =:kill-buffer= flag. But =work.org=,
which was
opened to get the refile targets, is still there.
Now we do the same operation, but refile it to the heading =* Work
tasks=
instead.
If we then list-buffers again, we find that =work.org= is not only
trailing, but
has been left unsaved.
Now we first visit =home.org= and start a capture and end it refiling to
the
heading =* Work tasks=.
Notice here in particular that =home.org= is killed, even though it was
being
visited before the capture process started. This does not correspond to
documented behavior of =:kill-buffer=.
Summing up:
1. When refiling anywhere, all agenda files (as we set them as refile
targets)
are visited to supply refile targets, so any of those which are not
the
base of a capture template are left open, even when option
:kill-buffer is
set.
2. In this same case, if the refile operation is done to a file which is
not
the capture base file, the other file is left both modified and
trailing.
3. In this same case, even if =:kill-buffer= is not set, the other file
is left
unsaved after refile.
4. Furthermore, when =:kill-buffer= is set, when leaving the capture
operation
with =org-capture-refile= the capture base file is killed
independently of
whether it was opened before or not (contrary to what is stated in
the
documentation about it).
I understand, of course, that the refile operation is an independent one
which
is layered upon =org-capture=. So items 1-3 there would, in this sense
be
"expected". But, I meant to show with these cases, which I don’t think
can be
labeled "corner" ones, that some further integration between
=org-capture= and
=org-capture-refile= would be welcome. Item 4, is indeed a behavior
that does
not correspond to documentation and, to my understanding, should be
considered
a bug.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-04-19
Package: Org mode version 9.2.4 (9.2.4-11-g1c3eae-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((org-agenda-files :maxlevel . 2))
org-agenda-files '("~/org/home.org" "~/org/work.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
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-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell
[O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi all,
When the capture template ends with a newline character and the capture
process is canceled, the following heading gets demoted. And it
shouldn’t.
Consider the following scenario. We have an agenda file with the
following content:
#+name: ~/org/agenda.org
#+begin_src org
,* Capture
,* Following heading
#+end_src
We start ~emacs -Q~, and do some basic setup:
#+begin_src emacs-lisp
(package-initialize)
(global-set-key (kbd "C-c c") 'org-capture)
(setq org-agenda-files
'("~/org/agenda.org"))
(setq org-refile-targets
'((org-agenda-files :maxlevel . 2)))
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/agenda.org" "Capture")
"* TODO %?\n")))
#+end_src
Now we start capture with "C-c c t" and cancel it with "C-c
k". Examination of "agenda.org" will show:
#+name: ~/org/agenda.org
#+begin_src org
,* Capture
,** Following heading
#+end_src
Both the line between them is gone, and "* Following heading" got
demoted, which is particularly unfortunate.
I’m not sure that I found a general rule in this respect. I had met
this effect before in my workflow and vaguely associated it with a
trailing "\n". Investigating it further, I could find a recipe to
reproduce the effect, as shown, but I don’t really know how general it
is.
This effect does not occur if "\n" is removed from the template, and I
don’t know if its inclusion is to be considered bad practice,
particularly as the capture templates already have a structure to handle
empty lines. But, if my memory does not betray me in this respect, one
will find plenty of those laying around in folks configs.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-04-19
Package: Org mode version 9.2.4 (9.2.4-11-g1c3eae-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((org-agenda-files :maxlevel . 2))
org-agenda-files '("~/org/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
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-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export
org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-
Re: [O] [RFC] Link-type for attachments, more attach options
Hi Ihor, > -Original Message- > From: Ihor Radchenko > Sent: den 27 juli 2019 16:56 > To: Gustav Wikström ; Nicolas Goaziou > Cc: emacs-orgmode@gnu.org > Subject: Re: [O] [RFC] Link-type for attachments, more attach options > I just found that removing ATTACH_DIR_INHERIT broke my current > configuration. I do not use ATTACH_DIR property - all the attachment > folders are created using ID. Also, I use ID property to store links to > entries. Therefore, inheriting ATTACH_DIR does nothing for me and > inheriting ID always gives the current entry's id value. At the end, I > cannot make a common attachment directory for the whole subtree, like I > was able to do with ATTACH_DIR_INHERIT. Ah, yes. That is an unfortunate side effect of ID properties having other use-cases outside of attachments. I thought about that for some time during the development but didn't get to implement any solution for it. The way I thought to do it was to create an algorithm that looks through the outline hierarchy at successively lower hierarchy for an ID property that has a corresponding attachment folder. If no folder exist for the ID attribute at the given level, the inherit functionality would continue to look at a lower level until a folder was found. I imagined the algorithm to look for both ID and DIR properties at each level and stop at the first property that had an existing attachment folder, with DIR taking precedence at each level if for some reason both ID and DIR based folders existed. Adding such functionality means going outside the scope of current property inheritance in Org mode. It adds some complexity but maybe it's warranted to do so here? But, as mentioned, I only got to the point of thinking about it, I didn't implement it. If someone wants to take up the challenge of implementing it then the starting point should be to modify org-attach-dir, replacing org-entry-get with something similar to the algorithm mentioned above. I might get to it at some point as well, but my motivation lies elsewhere right now (document-level stuff... see other threads by me). Kind regards Gustav
Re: [O] [RFC] Link-type for attachments, more attach options
Dear Gustav, Thanks for the update. For now, I fixed the problem for me with the following advice: #+begin_src emacs-lisp (define-advice org-attach-dir (:filter-return (dir) yant/org-attach-use-attach-dir-inheritance -100) "Use :ATTACH_DIR_INHERIT: property." (let ((attach-dir-inherited (and (org-entry-get-with-inheritance "ATTACH_DIR_INHERIT") (not (org-entry-get (point) "ATTACH_DIR_INHERIT" nil)) (org-with-point-at org-entry-property-inherited-from (org-attach-dir) (or attach-dir-inherited dir))) #+end_src Regards, Ihor Gustav Wikström writes: > Hi Ihor, > >> -Original Message- >> From: Ihor Radchenko >> Sent: den 27 juli 2019 16:56 >> To: Gustav Wikström ; Nicolas Goaziou >> >> Cc: emacs-orgmode@gnu.org >> Subject: Re: [O] [RFC] Link-type for attachments, more attach options > >> I just found that removing ATTACH_DIR_INHERIT broke my current >> configuration. I do not use ATTACH_DIR property - all the attachment >> folders are created using ID. Also, I use ID property to store links to >> entries. Therefore, inheriting ATTACH_DIR does nothing for me and >> inheriting ID always gives the current entry's id value. At the end, I >> cannot make a common attachment directory for the whole subtree, like I >> was able to do with ATTACH_DIR_INHERIT. > > Ah, yes. That is an unfortunate side effect of ID properties having > other use-cases outside of attachments. I thought about that for some > time during the development but didn't get to implement any solution > for it. The way I thought to do it was to create an algorithm that > looks through the outline hierarchy at successively lower hierarchy > for an ID property that has a corresponding attachment folder. If no > folder exist for the ID attribute at the given level, the inherit > functionality would continue to look at a lower level until a folder > was found. I imagined the algorithm to look for both ID and DIR > properties at each level and stop at the first property that had an > existing attachment folder, with DIR taking precedence at each level > if for some reason both ID and DIR based folders existed. > > Adding such functionality means going outside the scope of current > property inheritance in Org mode. It adds some complexity but maybe > it's warranted to do so here? But, as mentioned, I only got to the > point of thinking about it, I didn't implement it. > > If someone wants to take up the challenge of implementing it then the > starting point should be to modify org-attach-dir, replacing > org-entry-get with something similar to the algorithm mentioned above. > > I might get to it at some point as well, but my motivation lies > elsewhere right now (document-level stuff... see other threads by > me). > > Kind regards > Gustav
Re: [O] Links in Org-mode : Clunky
Dear Nathan, > Has anyone coded such a plugin or am I missing some cool Helm-fu? Not exactly the same, but see the code below. Note that the code does not support creating CUSTOM_ID. Instead, it silently creates an ID if it does not exist (see (org-id-get ... 'create)). The helm completion will work if it is enabled globally. #+begin_src emacs-lisp (defvar org-id-history nil "ID completion history for id: link type.") (defvar org-id-cache nil "ID completion cache for id: link type.") (defun org-id-prompt-id () "Prompt for the id during completion of att-id: link." (let ((org-refile-history org-id-history) (org-refile-cache org-id-cache) (org-refile-target-verify-function nil)) (let ((prompt-ans (org-refile-get-location "Select org entry"))) (prog1 (or (org-id-get (seq-find #'markerp prompt-ans) 'create) (user-error "Cannot find ID of the entry: %s" prompt-ans)) (setq org-id-history org-refile-history) (setq org-id-cache org-refile-cache) (defun org-id-link-complete (&optional arg) "Completion function for id: link." (let* ((id (org-id-prompt-id))) (format "id:%s" id))) (org-link-set-parameters "id" :complete #'org-id-link-complete) #+end_src Regards, Ihor Nathan Neff writes: > Hello all, > > I've always found that the links in org-mode are basically > very clunky to try to use in a quick fashion. > > To my understanding (see my other question about CUSTOM_ID > versus ID) it's a good practice to store either a CUSTOM_ID or ID > - (still can't grok the difference) and then store a hyperlink to that > CUSTOM_ID or ID. > > By storing a hyperlink to CUSTOM_ID or ID my heading can change, > but this won't matter. I can also move the heading to another file, and > links > to it will still work. > > However, I find that it's pretty clunky to store a CUSTOM_ID or ID > for a heading, and then copy the link, and then paste it where I want to > use it. Granted, it's not very difficult using org-store-link and > org-insert-link, > but it's just not as easy as I would think it would be. > > I've recently stumbled on Helm and was wondering if anyone has coded some > kind of function that would show me a list of my headings, and create a > CUSTOM_ID > or ID for the heading and then copy a link to that heading so that I could > easily paste it. > > Let's say I'm typing some stuff and want to insert a link to another > heading, I would > press some key combo and a helm search would come up. I would find the > heading that > I want to link to. If the heading has a CUSTOM_ID property, then a link to > that CUSTOM_ID > would be inserted at the text where my cursor is. If there's not a > CUSTOM_ID property perhaps a prompt for a CUSTOM_ID could pop up. Once I > enter the CUSTOM_ID, the link is created and copied to my cursor location / > clipboard. > > Has anyone coded such a plugin or am I missing some cool Helm-fu? > > Thanks, > --Nate
Re: [O] Bug: Saving and killing buffers with org-capture-refile and multiple agenda files [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
for ehalth reasons unable to comprehend this, but incase it is useful will point out that i do o9nt need teh refile feature. i always refile, and then finalizet he acpture. which is a no-op. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
Re: [O] CUSTOM_ID vs ID
Nicolas Goaziou writes: > Nathan Neff writes: > >> I've often been confused why org-mode has both a CUSTOM_ID >> and a ID property. I mean, why not just use one or the other name? > > Custom ID are user-defined, and only meaningful in the scope of the > document. Also, they may appear as-is when exported, e.g., as an anchor > in HTML. > > ID are (or should be) generated by Org, and are valid across files, > which means they need to be absolutely unique. Can you talk a little bit about how IDs are generated so that they are absolutely unique? > Org keeps track of ID if `org-id-track-globally' is non-nil (the > default). If this is nil, there is almost no difference between ID and > custom ID. > >> When would I ever have both an ID and a CUSTOM_ID property for >> a heading? > > You may want to refer to a heading from anywhere with id:... but need > a clean anchor in HTML export, for example. IDs sound like something that would be useful for synchronizing information between two (or more) separate Org systems - the ID could be updated whenever a change occurs and then used to determine what needs synchronization. True? -- David
[O] Changing the face of the capture template ?
Sorry for asking such a beginner question. I'm using a non monospace font for my daily work and I'd like to have the capture template buffer be in monospace. How do I do that ? Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune
Re: [O] CUSTOM_ID vs ID
Hello, David Masterson writes: > Can you talk a little bit about how IDs are generated so that they are > absolutely unique? See `org-id-new'. By default, it uses "uuidgen" command. > IDs sound like something that would be useful for synchronizing > information between two (or more) separate Org systems - the ID could be > updated whenever a change occurs and then used to determine what needs > synchronization. True? I think this is different. ID property is meant to never change once created. If you update it, you lose the reference to the headline, which defeats the intended purpose. Regards, -- Nicolas Goaziou
