Re: org-capture-templates: %date is too long
> Uwe Brauer writes: Uwe> Sorry, you misunderstood me, this time string, inserts the time string, Uwe> when I execute the capture, but I want to extract the time string, when Uwe> the message was received. This is why I used Uwe> %:date Uwe> in my first attempt, that works but inserts Uwe> Tue, 2 Mar 2021 19:35:03 +0100 Uwe> Which I find way too long. Uwe> Just Uwe> Tue, 2 Mar 2021 Uwe> Would be fine or 02.03.2021 Uwe> But not the hour, seconds etc > Capture templates allow inclusion of an arbitrary elisp expression with > %(EXP). You could try defining an elisp function which accepts %:date as > an argument (i.e. a string arg) and formats it using normal elisp date/time > functions and > returns the result as a string and then call that function within your > template? Ah, ok now I see I will give it a try at the weekend. smime.p7s Description: S/MIME cryptographic signature
Re: Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)]
I recall at least a few threads over the years that may be useful in thinking about this issue. Here are the ones I quickly found again: https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00221.html https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00052.html Josiah
Re: Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)]
Qqwy/Wiebe-Marten writes:
> With `org-list-allow-alphabetical` on, it is possible to use syntax like
>
> `a.`, `b.`, `c.` to create lists.
>
> However, the LaTeX that is exported will still create normal `enumerize`
> lists that do /not/ show up as alphabetical but rather still use `1.`,
> `2.`, `3.` for numbering.
>
> I think this current behaviour is at the very least surprising, and
> possibly unintended.
To fix this I think we will probably require:
\renewcommand{\theenumi}{\alph{enumi}}
Which will need i's added to match the depth (e.g. \thenumii).
I expect this can be done within the enum env.
--
Timothy
Dendron
I just heard about the note-taking tool Dendron, and am passing the link along because it has similarities to Org. It's always worth seeing what related projects are doing: https://dendron.so/ "Dendron is an open-source, local-first, markdown-based, note-taking tool built on top of VSCode. Like most such tools, Dendron supports all the usual features you would expect like tagging, backlinks, a graph view, split panes, and so forth. But it doesn't stop there - whereas most tools (try to make it) easy to get notes in, they tend to make it hard to get them back out later, and it only gets worse as you add more notes. Dendron helps you get notes back out and works better the more notes you have." There's a note page about handling Org files (just for the markup): https://dendron.so/notes/c3800271-dd56-46fb-8de7-e850f3c006b7.html Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ Caveat lector. --- STAPLR: https://staplr.org/
Re: org-refile failed due to default option stored by org-goto
if you are willing to try something as a complete stab in the dark,
here is something i have had from many years ago that fixed issues
possibly including a defaulting issue. the issues include other stuff
too, but i do not understand the code now for health reasons to rule
this out as a solution to your problem in addition to the problem i
put in the comment and name. i havce carried along this patch for
eyars.
commit deaa14b6ed264c259a1f3b805b67b2db3951ba20
Author: Your Name
Date: 2020-09-20 13:30:55 -0700
=== alpha remove the parens from ido completion of olpaths
Modified lisp/org-refile.el
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 1e6872b46..8f98e9cf9 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -617,7 +617,9 @@ this function appends the default value from
(tbl (mapcar
(lambda (x)
(if (and (not (member org-refile-use-outline-path
- '(file full-file-path)))
+ ;; === alpha remove the parens
from ido completion of olpaths
+ '(nil full-file-path)))
+ ;; '(file full-file-path)))
(not (equal filename (nth 1 x
(cons (concat (car x) extra " ("
(file-name-nondirectory (nth 1 x)) ")")
On 3/4/21, Maxim Nikulin wrote:
> On 03/03/2021 00:15, Maxim Nikulin wrote:
>>
>> There is one issue however. Default option option does not work if after
>> cache clean other command is called, e.g.
>> - jump using C-u C-c C-j
>> - clean cache C-u C-u C-u C-c C-w
>> - try to jump or to refile [C-u] C-c C-w to default offered option
>> - "user-error: Invalid target location"
>
> I have realized that this issue is rather loosely related to
> org-refile-use-cache and I have seen it in a worse variant with disabled
> cache.
>
> file init-refile.el:
>
> (package-initialize)
>
> (custom-set-variables
> '(org-agenda-files (quote ("~/examples/org/test-notes.org")))
> '(org-capture-templates
> (quote
> (("t" "Test" entry
>(file "")
>"* %?\n\n%U\n" :empty-lines 1
> '(org-default-notes-file "~/examples/org/capture.org")
> '(org-directory "~/examples/org/")
> '(org-modules (quote (org-refile)))
> '(org-outline-path-complete-in-steps nil)
> '(org-refile-targets (quote ((nil :maxlevel . 5) (org-agenda-files
> :maxlevel . 5
> '(org-refile-use-outline-path t)
> )
>
> emacs -Q -L ~/src/emacs/org-mode/lisp/ -L
> ~/src/emacs/org-mode/contrib/lisp/ -l ~/examples/org/init-refile.el
> ~/examples/org/test-notes.org
>
> - C-u C-c C-j (org-goto) to some heading in the test-notes.org, e.g.
> "Two" / "Third" / "Theme"
> - M-x org-capture RET t to capture some note
> - Let's assume that target of previously executed org-goto suits for
> this note
> - C-c C-w RET to refile the note from capture.org file to the heading in
> test-notes.org offered as the default option.
>
> Actual result:
> - "Invalid target location"
> - Captured note is still in the capture.org file but it is not apparent
> since capture frame is closed.
>
> Expected result:
> - Default option works for refile even if it is remained from org-goto
> command
>
> Side note. In some cases it not so easy to close capture frame. If
> org-default-note-file is configured to a file in a non-existing
> directory then C-c C-k asks to create that directory but does not
> discards the note.
>
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Culling org files
trs> [smaller files] My agenda is not cluttered. it is not clear to me why more smaller files and shallower trees in the outline would improve the agenda. sounds good though. tim> naming convention ... to determine what is included this is also what i do. org-agenda-files is just set at startup according to basename pattern. On 3/4/21, Tim Cross wrote: > > TRS-80 writes: > >> On 2021-03-03 16:59, Samuel Wales wrote: >> I have come to similar conclusion about "don't let org files get too >> big." Besides agenda speed, I think it is just easier to >> conceptualize things when each file covers only a limited scope, trees >> are more shallow, etc. >> >> So, lately (last year or more), I have been trying a "many small (up >> to perhaps medium)" instead of "few big" files approach (along with >> some custom tooling) and it has been working /a lot/ better for me. I >> really feel on top of things for the first time in a long time. My >> agenda is not cluttered. I can focus on important things, while not >> losing track of the rest, etc. >> > > I agree with this. I have a similar approach. I consider the file system > and org files to be the initial 'structure' and have many smaller files > rather than a couple of very large ones. Only a subset of files play a > role in the agenda (I'm still experimenting with two different > approaches for this - one uses a couple of functions which can > dynamically change the agenda list and the other uses a naming > convention which is used as the basis of a search to determine what is > included in the agenda. Final rsult will likely be a combination). > > My use pattern also constantly evolves as my requirements and priorities > change. It is and probably always will be, a work in progress! > > -- > Tim Cross > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: org-refile-use-cache and jumps using org-refile or org-goto
interesting. that would be great to speed it up. [i just meant that
the file list used to be correct.]
but it is slow these days. for me, (benchmark-run 1 (length
(org-refile-get-targets))) is 8s for 5886 targets.
i presume you mean something like that up heading is unnecessary
because you can keep a running olpath as you search.
On 3/4/21, Maxim Nikulin wrote:
> On 03/03/2021 09:34, Samuel Wales wrote:
>>
>> until recently in maint, ido and ido hacks with both refile and refile
>> goto [note: org-refile with a goto arg, not org-goto] has worked
>> perfectly. with no cache. now, there is an issue, where with no
>> cache that i know of, the first use, or the first use in a long time,
>> will actually present a huge file list that includes crazy elements
>> and is not constrained by even the verify function.
>
> Concerning performance. After reading your message I have realized that
> it should be really fast to extract several thousand headings from a
> buffer using regexp. However actually it is not so:
>
> (benchmark-run 10 (and (org-refile-get-targets) nil))
> | 9.86874253399 | 40 | 2.3275596 |
>
> So preparing the list of refile targets currently takes almost precisely
> 1 second. It is slow. Results are same for org-9.1.6 and
> release_9.4.4-231-gf46925. I am surprised however that 9.1.6 and 9.3.1
> are installed as system packages and have compiled files. I have not
> compiled git version but it works with the same speed.
>
> (length (org-refile-get-targets))
> : 3220
>
> Preferences:
>
>(require 'org-refile)
>(setq org-agenda-files '("~/notes/notes.org"))
>(setq org-refile-use-cache nil)
>(setq org-refile-use-outline-path t)
>(setq org-outline-path-complete-in-steps nil)
>(setq org-refile-targets '((org-agenda-files :maxlevel . 5)))
>
> Some lines from profile:
>
> - org-refile-get-targets 8414 74%
> ... - org-get-outline-path 7403 65%
> ... - org--get-outline-path-1 7286 64%
> ... - org-up-heading-safe6328 56%
>
> There is a room for improvement. Outline paths could be obtained in a
> single pass without backward search. It should speed up building the
> list of targets by 2 or 3 times.
>
> Though it is unrelated to issues with default option and cache entries
> when both ways to call org-refile are used: directly and through org-goto.
>
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: org-capture-templates: %date is too long
Uwe Brauer writes:
"RP" == Robert Pluim writes:
>
>>> On Thu, 04 Mar 2021 15:22:21 +0100, Uwe Brauer
> said:
>Uwe> Sorry, you misunderstood me, this time string, inserts the time
> string,
>Uwe> when I execute the capture, but I want to extract the time string,
> when
>Uwe> the message was received. This is why I used
>Uwe> %:date
>Uwe> in my first attempt, that works but inserts
>Uwe> Tue, 2 Mar 2021 19:35:03 +0100
>
>Uwe> Which I find way too long.
>
>Uwe> Just
>Uwe> Tue, 2 Mar 2021
>
>Uwe> Would be fine or 02.03.2021
>
>Uwe> But not the hour, seconds etc
>
>> It looks like the %:date handling respects the
>> 'org-time-stamp-formats' variable, so if you can arrange for that to
>> be let-bound appropriately during the capture process, it might do the
>> right thing.
>
> Hm that variable is set to
>
> Its value is ("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
>
> So if I call with a prefix it inserts
> <2021-03-04 jue 21:19>
>
> But nothing like +0100
>
> I am not acquainted with let-bound (only with let)
>
> So are you saying I should may use defadvice to modify org-capture?
Capture templates allow inclusion of an arbitrary elisp expression with
%(EXP). You could try defining an elisp function which accepts %:date as
an argument (i.e. a string arg) and formats it using normal elisp date/time
functions and
returns the result as a string and then call that function within your
template?
--
Tim Cross
Re: org-capture-templates: %date is too long
>>> "RP" == Robert Pluim writes:
>> On Thu, 04 Mar 2021 15:22:21 +0100, Uwe Brauer said:
Uwe> Sorry, you misunderstood me, this time string, inserts the time string,
Uwe> when I execute the capture, but I want to extract the time string, when
Uwe> the message was received. This is why I used
Uwe> %:date
Uwe> in my first attempt, that works but inserts
Uwe> Tue, 2 Mar 2021 19:35:03 +0100
Uwe> Which I find way too long.
Uwe> Just
Uwe> Tue, 2 Mar 2021
Uwe> Would be fine or 02.03.2021
Uwe> But not the hour, seconds etc
> It looks like the %:date handling respects the
> 'org-time-stamp-formats' variable, so if you can arrange for that to
> be let-bound appropriately during the capture process, it might do the
> right thing.
Hm that variable is set to
Its value is ("<%Y-%m-%d %a>" . "<%Y-%m-%d %a %H:%M>")
So if I call with a prefix it inserts
<2021-03-04 jue 21:19>
But nothing like +0100
I am not acquainted with let-bound (only with let)
So are you saying I should may use defadvice to modify org-capture?
smime.p7s
Description: S/MIME cryptographic signature
Re: Culling org files
TRS-80 writes: > On 2021-03-03 16:59, Samuel Wales wrote: > I have come to similar conclusion about "don't let org files get too > big." Besides agenda speed, I think it is just easier to > conceptualize things when each file covers only a limited scope, trees > are more shallow, etc. > > So, lately (last year or more), I have been trying a "many small (up > to perhaps medium)" instead of "few big" files approach (along with > some custom tooling) and it has been working /a lot/ better for me. I > really feel on top of things for the first time in a long time. My > agenda is not cluttered. I can focus on important things, while not > losing track of the rest, etc. > I agree with this. I have a similar approach. I consider the file system and org files to be the initial 'structure' and have many smaller files rather than a couple of very large ones. Only a subset of files play a role in the agenda (I'm still experimenting with two different approaches for this - one uses a couple of functions which can dynamically change the agenda list and the other uses a naming convention which is used as the basis of a search to determine what is included in the agenda. Final rsult will likely be a combination). My use pattern also constantly evolves as my requirements and priorities change. It is and probably always will be, a work in progress! -- Tim Cross
Re: Free up C-c SPC/org-table-blank-field?
Carsten Dominik writes: > On Fri, Feb 5, 2021 at 7:33 PM Eric Abrahamsen > wrote: > >> Carsten Dominik writes: >> >> > On Fri, Feb 5, 2021 at 11:13 AM Christian Moe >> wrote: >> > >> >> >> >> Tim Cross writes: >> >> >> >> > Eric Abrahamsen writes: >> >> > >> >> >>> Does it actually need a key binding? I've never used it and just use >> >> >>> to move to the next field, leaving the field blank. >> >> >> >> >> >> I assume it's meant for blanking a field you've already typed >> something >> >> >> into. But yes, I can't imagine it's a heavily-used command, and I >> >> >> suspect the C-c binding is mostly mnemonic: "make this field >> >> >> contain only blanks". >> >> >> >> >> > >> >> > I guess that makes sense, but not convinced the use of a valuable key >> >> > binding is justified given the need. Then again, others probably have >> >> > vastly different use cases to mine. >> >> >> >> One can also blank a field by pressing immediately after tabbing >> >> into it. So C-c isn't strictly needed. >> >> >> > >> > Hi, >> > >> > I think there would be minimal impact from releasing this key binding. >> So >> > I think we could remove it. >> >> Well that would be pretty nice, if you don't think it would be too >> disruptive. Shall I prepare a patch? >> > > I am not taking the decisions, but I would say: yes, please do. That took a while, for such a simple patch! Hope this is acceptable. Thanks, Eric >From c7d246b20f56bcc89a23d523ebf64a2f67c58bc6 Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen Date: Thu, 4 Mar 2021 11:44:12 -0800 Subject: [PATCH] Remove default binding for org-table-blank-field * lisp/org-keys.el: The command isn't useful enough to occupy such a useful keybinding as "C-c SPC". --- lisp/org-keys.el | 2 -- 1 file changed, 2 deletions(-) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index f0fdb79ea..07ff85349 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -174,7 +174,6 @@ (declare-function org-show-subtree "org" ()) (declare-function org-sort "org" ( with-case)) (declare-function org-sparse-tree "org" ( arg type)) -(declare-function org-table-blank-field "org" ()) (declare-function org-table-copy-down "org" (n)) (declare-function org-table-create-or-convert-from-region "org" (arg)) (declare-function org-table-create-with-table\.el "org-table" ()) @@ -620,7 +619,6 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names." (org-defkey org-mode-map (kbd "RET") #'org-return) (org-defkey org-mode-map (kbd "C-j") #'org-return-and-maybe-indent) (org-defkey org-mode-map (kbd "C-c ?") #'org-table-field-info) -(org-defkey org-mode-map (kbd "C-c SPC") #'org-table-blank-field) (org-defkey org-mode-map (kbd "C-c +") #'org-table-sum) (org-defkey org-mode-map (kbd "C-c =") #'org-table-eval-formula) (org-defkey org-mode-map (kbd "C-c '") #'org-edit-special) -- 2.30.1
Re: Culling org files
On 2021-03-03 16:59, Samuel Wales wrote: along lines of reducing logbook entries I guess you must have picked up on my comment in another recent thread. :) i often want to reduce org files, and i wonder if anybody already had the same desire. here are some random ideas. my org files are so large i might have written this list a few times 1) list links to duplicate headlines 2) list links to duplicate body text 3) list links to duplicate entries 4) list links to duplicate entries, body text, or headlines using fuzzy matching - suppose you captured an email slightly differently a few times 5) show in agenda the biggest few tasks so you can go to them and reduce them or doneify them 6) (waves hands) git magic to find old entries that might be stale 7) show in agenda the tasks with biggest logbook drawers so you can go to them and reduce them 8) find similar body text that are in distant subtrees that might be candidates for refactoring using org-id linking 9) show in agenda deepest olpath levels 10) indicate deep, shallow, text-filled, etc. top levels 11) show in agenda entries with most children 12) archive logbook drawer entries older than 1 year - get rid of drawer if empty - put the drawer entries into a logbook drawer in a new task, with a similar header, that then gets doneified. then that gets archived when you archive stuff. 13) operate on lines matching a pattern - e.g. "* [2021-02-17 Wed 20:35] whatever" lines might be insubstantial notes that do not need to clutter the inactive timestamp display in the agenda and thus should be moved to a target location with query - that target location would presumably not be in an agenda file 14) function to lint all agenda files 15) reduce false positives in lint well, idk if htese are good ideas. just thought maybe we could form a cult of "don't let org files get too big". I have come to similar conclusion about "don't let org files get too big." Besides agenda speed, I think it is just easier to conceptualize things when each file covers only a limited scope, trees are more shallow, etc. So, lately (last year or more), I have been trying a "many small (up to perhaps medium)" instead of "few big" files approach (along with some custom tooling) and it has been working /a lot/ better for me. I really feel on top of things for the first time in a long time. My agenda is not cluttered. I can focus on important things, while not losing track of the rest, etc. I could write a whole lot about my "custom tooling" but as that is an entire package in its own right (still in experimental development and thus unreleased), I will limit my comments here only to the "archival" portion of this problem. I realized, at least in my case, after mulling this over for some time, that there seem to be a few distinct cases which would need to be handled by a custom archival function: - If the TODO is still active, and the number of logbook entries exceed some (definable) threshold, either move the older entries to a similarly named archive file/heading, or (also definable) simply delete them. This would cover things like habits and other recurring tasks that tend to generate lots and lots of entries over time. This is perhaps the part I mentioned in the other thread recently. - If the TODO is completed (and perhaps also after it becomes a certain (again, definable) age), then move the whole TODO to a similarly named archive file. - There was another, but I think it was for the case where the entire file is a project (which is a bit specific to my own setup). Ideally, this custom function would handle all the above cases, and could be called with point at each headline, so it would be easy to map over a file or even a directory full of files, in order to automate the archival process (perhaps annually?). Cheers, TRS-80
Re: org-capture-templates: %date is too long
> On Thu, 04 Mar 2021 15:22:21 +0100, Uwe Brauer said: Uwe> Sorry, you misunderstood me, this time string, inserts the time string, Uwe> when I execute the capture, but I want to extract the time string, when Uwe> the message was received. This is why I used Uwe> %:date Uwe> in my first attempt, that works but inserts Uwe> Tue, 2 Mar 2021 19:35:03 +0100 Uwe> Which I find way too long. Uwe> Just Uwe> Tue, 2 Mar 2021 Uwe> Would be fine or 02.03.2021 Uwe> But not the hour, seconds etc It looks like the %:date handling respects the 'org-time-stamp-formats' variable, so if you can arrange for that to be let-bound appropriately during the capture process, it might do the right thing. Robert --
Bug: alphabetical lists will not show up as such in LaTeX export [9.3.6 (9.3.6-71-g7684b5-elpaplus @ /home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)]
Dear org-mode community,
With `org-list-allow-alphabetical` on, it is possible to use syntax like
`a.`, `b.`, `c.` to create lists.
However, the LaTeX that is exported will still create normal `enumerize`
lists that do /not/ show up as alphabetical but rather still use `1.`,
`2.`, `3.` for numbering.
I think this current behaviour is at the very least surprising, and
possibly unintended.
Thank you for your time and consideration!
~Marten / Qqwy
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.22, cairo version 1.17.3)
of 2020-08-28
Package: Org mode version 9.3.6 (9.3.6-71-g7684b5-elpaplus @
/home/qqwy/.emacs.d/elpa/org-plus-contrib-20200518/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-latex-listings 'minted
org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize)
org-roam-dailies-calendar-hook '(org-roam-dailies-calendar-mark-entries)
org-fc-index-function 'org-fc-awk-index
org-link-shell-confirm-function 'yes-or-no-p
org-babel-after-execute-hook '(spacemacs/ob-fix-inline-images)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-roam-title-to-slug-function 'org-roam--title-to-slug
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-roam-mode-hook '(org-roam-bibtex-mode)
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-latex-pdf-process '("latexmk -shell-escape -bibtex -pdf %f")
org-imenu-depth 8
org-download-annotate-function 'org-download-annotate-default
org-roam-bibtex-mode t
org-agenda-files
'("/run/media/qqwy/Serendipity/Programming/RUG/ShortProgrammingProject/repo/report/report.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-modules '(org-roam-protocol ol-w3m ol-bbdb ol-bibtex ol-docview
ol-gnus ol-info ol-irc ol-mhe
ol-rmail ol-eww)
org-roam-buffer-prepare-hook '(org-roam-buffer--insert-title
org-roam-buffer--insert-backlinks
org-roam-buffer--insert-ref-links)
org-mode-hook '(org-fragtog-mode
(lambda nil (define-key org-mode-map (kbd "") 'org-export-as-pdf))
spacemacs/load-yasnippet toc-org-enable org-download-enable
org-bullets-mode
spacemacs//org-babel-do-load-languages spacemacs/add-org-surrounds
evil-org-mode
spacemacs/delay-emoji-cheat-sheet-hook
#[0 "\301\211\207" [imenu-create-index-function org-imenu-get-tree] 2]
#[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
spacemacs//init-company-org-mode company-mode)
org-roam-mode t
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-restore-windows-after-quit t
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-with-inline-images t
org-roam-title-change-hook '(org-roam--update-file-name-on-title-change
org-roam--update-links-on-title-change)
org-download-file-format-function 'org-download-file-format-default
org-roam-capture-function 'org-capture
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-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-babel-load-languages '((emacs-lisp . t) (shell . t) (C . t) (haskell
. t))
org-log-done t
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME
CONTENTS WIDTH)"]
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-protocol-protocol-alist '(("org-roam-file" :protocol "roam-file"
:function
org-roam-protocol-open-file)
("org-roam-ref" :protocol "roam-ref" :function
org-roam-protocol-open-ref)
)
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-clock-persist-file "/home/qqwy/.emacs.d/.cache/org-clock-save.el"
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-babel-tangle-lang-exts '(("haskell" . "hs") ("D" . "d") ("C++" .
"cpp") ("emacs-lisp" . "el")
("elisp" . "el"))
org-format-latex-options '(:foreground default :background default
:scale 1.3 :html-foreground
"Black"
org-refile failed due to default option stored by org-goto
On 03/03/2021 00:15, Maxim Nikulin wrote:
There is one issue however. Default option option does not work if after
cache clean other command is called, e.g.
- jump using C-u C-c C-j
- clean cache C-u C-u C-u C-c C-w
- try to jump or to refile [C-u] C-c C-w to default offered option
- "user-error: Invalid target location"
I have realized that this issue is rather loosely related to
org-refile-use-cache and I have seen it in a worse variant with disabled
cache.
file init-refile.el:
(package-initialize)
(custom-set-variables
'(org-agenda-files (quote ("~/examples/org/test-notes.org")))
'(org-capture-templates
(quote
(("t" "Test" entry
(file "")
"* %?\n\n%U\n" :empty-lines 1
'(org-default-notes-file "~/examples/org/capture.org")
'(org-directory "~/examples/org/")
'(org-modules (quote (org-refile)))
'(org-outline-path-complete-in-steps nil)
'(org-refile-targets (quote ((nil :maxlevel . 5) (org-agenda-files
:maxlevel . 5
'(org-refile-use-outline-path t)
)
emacs -Q -L ~/src/emacs/org-mode/lisp/ -L
~/src/emacs/org-mode/contrib/lisp/ -l ~/examples/org/init-refile.el
~/examples/org/test-notes.org
- C-u C-c C-j (org-goto) to some heading in the test-notes.org, e.g.
"Two" / "Third" / "Theme"
- M-x org-capture RET t to capture some note
- Let's assume that target of previously executed org-goto suits for
this note
- C-c C-w RET to refile the note from capture.org file to the heading in
test-notes.org offered as the default option.
Actual result:
- "Invalid target location"
- Captured note is still in the capture.org file but it is not apparent
since capture frame is closed.
Expected result:
- Default option works for refile even if it is remained from org-goto
command
Side note. In some cases it not so easy to close capture frame. If
org-default-note-file is configured to a file in a non-existing
directory then C-c C-k asks to create that directory but does not
discards the note.
Re: org-capture-templates: %date is too long
>>> "AA" == Alberto AP writes: Hi > Hi > What I use is the result of format-time-string (as explained in the Org > Capture Templates help; check also the help for the format-time-string > function). > The string I use is: > %<%Y%m%d-T%H%M%S> > It gives me, for example, 20210304-T095526. > If you don't want the hour just remove "-T%H%M%S" Sorry, you misunderstood me, this time string, inserts the time string, when I execute the capture, but I want to extract the time string, when the message was received. This is why I used %:date in my first attempt, that works but inserts Tue, 2 Mar 2021 19:35:03 +0100 Which I find way too long. Just Tue, 2 Mar 2021 Would be fine or 02.03.2021 But not the hour, seconds etc Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
Re: org-refile-use-cache and jumps using org-refile or org-goto
On 03/03/2021 09:34, Samuel Wales wrote:
until recently in maint, ido and ido hacks with both refile and refile
goto [note: org-refile with a goto arg, not org-goto] has worked
perfectly. with no cache. now, there is an issue, where with no
cache that i know of, the first use, or the first use in a long time,
will actually present a huge file list that includes crazy elements
and is not constrained by even the verify function.
Concerning performance. After reading your message I have realized that
it should be really fast to extract several thousand headings from a
buffer using regexp. However actually it is not so:
(benchmark-run 10 (and (org-refile-get-targets) nil))
| 9.86874253399 | 40 | 2.3275596 |
So preparing the list of refile targets currently takes almost precisely
1 second. It is slow. Results are same for org-9.1.6 and
release_9.4.4-231-gf46925. I am surprised however that 9.1.6 and 9.3.1
are installed as system packages and have compiled files. I have not
compiled git version but it works with the same speed.
(length (org-refile-get-targets))
: 3220
Preferences:
(require 'org-refile)
(setq org-agenda-files '("~/notes/notes.org"))
(setq org-refile-use-cache nil)
(setq org-refile-use-outline-path t)
(setq org-outline-path-complete-in-steps nil)
(setq org-refile-targets '((org-agenda-files :maxlevel . 5)))
Some lines from profile:
- org-refile-get-targets 8414 74%
... - org-get-outline-path 7403 65%
... - org--get-outline-path-1 7286 64%
... - org-up-heading-safe6328 56%
There is a room for improvement. Outline paths could be obtained in a
single pass without backward search. It should speed up building the
list of targets by 2 or 3 times.
Though it is unrelated to issues with default option and cache entries
when both ways to call org-refile are used: directly and through org-goto.
Re: org-capture-templates: %date is too long
Hi
What I use is the result of format-time-string (as explained in the Org
Capture Templates help; check also the help for the format-time-string
function).
The string I use is:
%<%Y%m%d-T%H%M%S>
It gives me, for example, 20210304-T095526.
If you don't want the hour just remove "-T%H%M%S"
Best,
Alberto
Uwe Brauer writes:
> Hi
>
> I try to add a new entry to my org-capture-templates
> for mails what I read via gnus. I'd like to have a timestamp that
> reflects when the message was received, not when the entry was created
> (for that I would to have to use %t)
>
> Now I have set
>
> "| | %:fromname|%:fromaddress|%^{Sheet|1|2|3|4|5|6|7|8|9} | %:date
> |[ ] | | %a " :prepend t)
>
> Using the description of the org-capture-template
>
> +--
> gnus| %:from %:fromname %:fromaddress
> | %:to %:toname %:toaddress
> | %:fromto (either "to NAME" or "from NAME")
> | %:date %:date-timestamp (as active timestamp)
> | %:date-timestamp-inactive (as inactive timestamp)
> gnus| %:group, for messages also all email fields
>
> The problem is this results in
>
> | Number | name | email | sheet | date
>| status |
> || John Doe | foot...@gmail.com | 2 | Tue, 2 Mar 2021 19:35:03
> +0100 | [ ]|
>
> I don't need the hour, and for sure I don't need +0100
>
> Any idea how to shorten that?
>
> regards
>
> Uwe Brauer
Re: [PATCH] Reduce code duplication in ob-sql.el and ob-sqlite.el
Please see the attached updated patch with the changes requested. Nick On 3/4/21 12:25 AM, Kyle Meyer wrote: Nick Savage writes: Hi everyone, See the attached patch. It is a small change to reduce code duplication between ob-sql.el and ob-sqlite.el by reusing org-babel-sql-expand-vars as suggested by the FIXME in ob-sqlite.el. Thank you. Looks good, though I think it'd be nice to keep org-babel-sqlite-expand-vars around for a bit, marked as obsolete. Subject: [PATCH] Reduce code duplication in ob-sqlite.el and ob-sql.el * lisp/ob-sqlite.el (org-babel-sqlite-expand-vars): removed function to replace with ob-sql.el version * lisp/ob-sql.el (org-babel-sql-expand-vars): updated to support expanding sqlite vars Please capitalize the first word after ":" and end the entries with a period. https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html -(defun org-babel-sqlite-expand-vars (body vars) - "Expand the variables held in VARS in BODY." - ;; FIXME: Redundancy with org-babel-sql-expand-vars! - (mapc - (lambda (pair) - (setq body - (replace-regexp-in-string - (format "$%s" (car pair)) - (let ((val (cdr pair))) - (if (listp val) - (let ((data-file (org-babel-temp-file "sqlite-data-"))) -(with-temp-file data-file - (insert (orgtbl-to-csv val nil))) -data-file) -(if (stringp val) val (format "%S" val - body))) - vars) - body) - How about marking this with (declare (obsolete ...)) and keeping it around as a wrapper that calls org-babel-sql-expand-vars? That will give any third-party code that may have used this for whatever reason (perhaps unlikely) a chance to update. >From 1e2816c89a4fc87a8d01c20dfb5a3c4cf794b553 Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Wed, 3 Mar 2021 07:47:15 -0500 Subject: [PATCH] Reduce code duplication in ob-sqlite.el and ob-sql.el * lisp/ob-sqlite.el (org-babel-sqlite-expand-vars): Marked function as obsolete. * lisp/ob-sql.el (org-babel-sql-expand-vars): Updated to support expanding sqlite vars. --- lisp/ob-sql.el| 15 +++ lisp/ob-sqlite.el | 23 +-- 2 files changed, 16 insertions(+), 22 deletions(-) diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el index 68d5ddd0a..b1c6920cb 100644 --- a/lisp/ob-sql.el +++ b/lisp/ob-sql.el @@ -350,8 +350,13 @@ SET COLSEP '|' (org-babel-pick-name (cdr (assq :rowname-names params)) (cdr (assq :rownames params -(defun org-babel-sql-expand-vars (body vars) - "Expand the variables held in VARS in BODY." +(defun org-babel-sql-expand-vars (body vars sqlite) + "Expand the variables held in VARS in BODY. + +If SQLITE has been provided, prevent passing a format to +`orgtbl-to-csv'. This prevents overriding the default format, which if +there were commas in the context of the table broke the table as an +argument mechanism." (mapc (lambda (pair) (setq body @@ -362,9 +367,11 @@ SET COLSEP '|' (let ((data-file (org-babel-temp-file "sql-data-"))) (with-temp-file data-file (insert (orgtbl-to-csv - val '(:fmt (lambda (el) (if (stringp el) + val (if sqlite + nil + '(:fmt (lambda (el) (if (stringp el) el -(format "%S" el))) +(format "%S" el data-file) (if (stringp val) val (format "%S" val body))) diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el index 6e21fa9fd..332a29872 100644 --- a/lisp/ob-sqlite.el +++ b/lisp/ob-sqlite.el @@ -27,6 +27,7 @@ ;;; Code: (require 'ob) +(require 'ob-sql) (declare-function org-table-convert-region "org-table" (beg0 end0 separator)) @@ -51,8 +52,8 @@ (defun org-babel-expand-body:sqlite (body params) "Expand BODY according to the values of PARAMS." - (org-babel-sqlite-expand-vars - body (org-babel--get-vars params))) + (org-babel-sql-expand-vars + body (org-babel--get-vars params) t)) (defvar org-babel-sqlite3-command "sqlite3") @@ -112,22 +113,8 @@ This function is called by `org-babel-execute-src-block'." (defun org-babel-sqlite-expand-vars (body vars) "Expand the variables held in VARS in BODY." - ;; FIXME: Redundancy with org-babel-sql-expand-vars! - (mapc - (lambda (pair) - (setq body - (replace-regexp-in-string - (format "$%s" (car pair)) - (let ((val (cdr pair))) - (if (listp val) - (let ((data-file (org-babel-temp-file "sqlite-data-"))) -(with-temp-file data-file - (insert (orgtbl-to-csv val nil))) -
org-capture-templates: %date is too long
Hi
I try to add a new entry to my org-capture-templates
for mails what I read via gnus. I'd like to have a timestamp that
reflects when the message was received, not when the entry was created
(for that I would to have to use %t)
Now I have set
"| | %:fromname|%:fromaddress|%^{Sheet|1|2|3|4|5|6|7|8|9} | %:date |[
] | | %a " :prepend t)
Using the description of the org-capture-template
+--
gnus| %:from %:fromname %:fromaddress
| %:to %:toname %:toaddress
| %:fromto (either "to NAME" or "from NAME")
| %:date %:date-timestamp (as active timestamp)
| %:date-timestamp-inactive (as inactive timestamp)
gnus| %:group, for messages also all email fields
The problem is this results in
| Number | name | email | sheet | date
| status |
|| John Doe | foot...@gmail.com | 2 | Tue, 2 Mar 2021 19:35:03
+0100 | [ ]|
I don't need the hour, and for sure I don't need +0100
Any idea how to shorten that?
regards
Uwe Brauer
Re: Using lexical-binding
> Kyle Meyer writes: >> Stefan Monnier writes: >> >>> Since I'm not using it, I can't really test the result in any meaningful >>> way. Furthermore, just like `calendar.el`, it relies on dynamic scoping >>> and `eval` in all kinds of ways, so it's very difficult to be sure the >>> result is "sufficiently similar" to the old behavior not to break some >>> funky use somewhere out there. >> >> I probably don't use many fancy agenda features, but I do work regularly >> from it. Running with these changes throughout today, I didn't notice >> any issues. Within the next few days, I'll try to test some non-default >> settings and more obscure features that I don't use as part of my normal >> workflow, and see if I can find any problems. > > I've continued to run with these changes and still haven't noticed any > problems. I've also tested various features (sticky agendas, block > agendas, option setting from custom commands) and didn't spot anything. > >> I'll also push the current changes to scratch/sm/agenda-lexical with the >> hope that others will test and report back. > > Has anyone else tried this out? I'm using that branch for several days now without any problem. LGTM! I did nothing special for the test though. At least I use column mode, Org habits and interaction with calendar. Thanks! -- Marco
