reference cards missing
Hi there! There is explicit reference at https://orgmode.org/worg/#learn to reference cards in PDF and ASCII format. The links are broken and the linked files do not exist in the git repo. This seems to be a new TODO. Regards, Cédric M. Campos Por favor ten en cuenta el medio ambiente antes de imprimir este correo-e. Please bear in mind the Environment before printing this email.
bug#51043: Fix build of rkdeveloptool
Hi,
Here's fix of the rkdeveloptool package which fails to build due to GCC
complaining about the truncation error.
See https://github.com/rockchip-linux/rkdeveloptool/pull/62.
PetrFrom 50e6bbcf7f648a7793ecf6b1ddd9a4148fc776b8 Mon Sep 17 00:00:00 2001
From: Petr Hodina
Date: Mon, 21 Feb 2022 13:25:16 +0100
Subject: [PATCH 1/2] gnu: rkdeveloptool: Fix build.
* gnu/packages/hardware.scm (rkdeveloptool): Update to newer commit 46bb4c.
[source]: Apply patch to fix GCC format truncation error.
[arguments]: Add phase after install to install udev rules.
* gnu/local.mk: Add patch.
* gnu/packages/patches/rkdeveloptool-fix-format-truncation.patch: New file.
diff --git a/gnu/local.mk b/gnu/local.mk
index dcee1611b2..3e84188937 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1754,6 +1754,7 @@ dist_patch_DATA = \
%D%/packages/patches/remake-impure-dirs.patch \
%D%/packages/patches/restic-0.9.6-fix-tests-for-go1.15.patch \
%D%/packages/patches/retroarch-LIBRETRO_DIRECTORY.patch \
+ %D%/packages/patches/rkdeveloptool-fix-format-truncation.patch \
%D%/packages/patches/rnp-add-version.cmake.patch \
%D%/packages/patches/rnp-disable-ruby-rnp-tests.patch \
%D%/packages/patches/rnp-unbundle-googletest.patch \
diff --git a/gnu/packages/hardware.scm b/gnu/packages/hardware.scm
index a3ce90f75e..e4aceab54b 100644
--- a/gnu/packages/hardware.scm
+++ b/gnu/packages/hardware.scm
@@ -770,29 +770,40 @@ (define-public wavemon
(license license:gpl3+)))
(define-public rkdeveloptool
- (let ((commit "6e92ebcf8b1812da02663494a68972f956e490d3")
-(revision "0"))
+ (let ((commit "46bb4c073624226c3f05b37b9ecc50bbcf543f5a")
+(revision "1"))
(package
(name "rkdeveloptool")
- (version (git-version "1.3" revision commit))
+ (version (git-version "1.32" revision commit))
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/rockchip-linux/rkdeveloptool";)
(commit commit)))
+ ;; https://github.com/rockchip-linux/rkdeveloptool/pull/62
+ (patches (search-patches "rkdeveloptool-fix-format-truncation.patch"))
(file-name (git-file-name name version))
(sha256
- (base32 "0zwrkqfxd671iy69v3q0844gfdpm1yk51i9qh2rqc969bd8glxga"
+ (base32 "0kb2ylsrqqrdf4np66yxmk96kdc5g8nvjx13gifpm5rshv5770bq"
(build-system gnu-build-system)
+ (arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ (add-after 'install 'install-udev-rules
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((udev (string-append (assoc-ref outputs "out")
+ "/lib/udev/rules.d")))
+ (mkdir-p udev)
+ (install-file "99-rk-rockusb.rules" udev)))
(native-inputs
(list autoconf automake pkg-config))
(inputs
(list libusb))
(home-page "https://github.com/rockchip-linux/rkdeveloptool";)
- (synopsis "Read from and write to RockChicp devices over USB")
+ (synopsis "Read/write to rockchip devices over USB")
(description
- "Rkdeveloptool can read from and write to RockChip devices over USB, such
+ "Rkdeveloptool can read from and write to rockchip devices over USB, such
as the Pinebook Pro.")
(license license:gpl2+
diff --git a/gnu/packages/patches/rkdeveloptool-fix-format-truncation.patch b/gnu/packages/patches/rkdeveloptool-fix-format-truncation.patch
new file mode 100644
index 00..fd9a193e76
--- /dev/null
+++ b/gnu/packages/patches/rkdeveloptool-fix-format-truncation.patch
@@ -0,0 +1,22 @@
+From bc9e5f03d71b3dd4360721f4df3524c1dcba9bc8 Mon Sep 17 00:00:00 2001
+From: Petr Hodina
+Date: Mon, 21 Feb 2022 13:00:53 +0100
+Subject: [PATCH] Fix format truncation for GCC >7.1.
+
+
+diff --git a/main.cpp b/main.cpp
+index 72bd94b..800db0b 100644
+--- a/main.cpp
b/main.cpp
+@@ -1490,7 +1490,7 @@ static bool saveEntry(FILE* outFile, char* path, rk_entry_type type,
+ static inline uint32_t convertChipType(const char* chip) {
+ char buffer[5];
+ memset(buffer, 0, sizeof(buffer));
+- snprintf(buffer, sizeof(buffer), "%s", chip);
++ memcpy(buffer, chip, 4);
+ return buffer[0] << 24 | buffer[1] << 16 | buffer[2] << 8 | buffer[3];
+ }
+
+--
+2.34.0
+
--
2.34.0
From 1ed30235dbaae9f95c34826051eb88f9d6def032 Mon Sep 17 00:00:00 2001
From: Petr Hodina
Date: Mon, 21 Feb 2022 13:33:41 +0100
Subject: [PATCH 2/2] gnu: Add rkdeveloptool-pine64.
* gnu/packages/hardware.scm (rkdeveloptool-pine64): New variable.
diff --git a/gnu/packages/hardware.scm b/gnu/packages/hardware.scm
index e4aceab54b..ceb63081b2 100644
--- a/gnu/packages/hardware.scm
+++ b/gnu/packages/hardware.scm
@@ -807,6 +807,41 @@ (define-public rkdeveloptool
as the Pinebook Pro.")
(license license:gpl2+
+(define-public rkdeveloptool-pine64
+ (package
+(name "rkdeveloptool-pine64")
+(version "1.1.0")
+(source (origin
+ (method git-fetch)
+
Re: Bug: SCHEDULED's end time wrong [9.5.2 (9.5.2-gfbff08 @ /Users/liutos/.emacs.d/elpa/org-9.5.2/)]
Sorry for missing the error's detail. Here it is ``` org-duration-to-minutes: Invalid duration format: "+0:29" ``` I seen this message from my Emacs' *Messages* buffer after I invoke org-agenda. And the *Org Agenda* buffer is empty except a simple title. Ihor Radchenko 于2022年2月20日周日 14:49写道： > Liutos writes: > > > Assume there is an entry as simple as following > > > > * a simple entry > > > > Move the cursor on the entry, then press C-c C-s for setting its > > SCHEDULED property. Then type `23:59+0:30` and press Enter key. The > > resulting SCHEDULED property will be an ill-formed value such as > > `<2022-02-19 Sat 23:59-24:29>`, which will cause error in org agenda. > > Could you clarify what kind of error is triggered? > <2022-02-19 Sat 23:59-24:29> is a perfectly valid date range format, > which should be handled by org-agenda without issues. > > Best, > Ihor > -- Liutos Love Linux LaTeX Lisp Ling 我的GitHub主页：https://github.com/Liutos
Re: Bug: SCHEDULED's end time wrong [9.5.2 (9.5.2-gfbff08 @ /Users/liutos/.emacs.d/elpa/org-9.5.2/)]
Liutos writes: > Sorry for missing the error's detail. Here it is > > ``` > org-duration-to-minutes: Invalid duration format: "+0:29" > ``` > > I seen this message from my Emacs' *Messages* buffer after I invoke > org-agenda. And the *Org Agenda* buffer is empty except a simple title. Thanks for the additional information! I am unable to reproduce the issue on my side. Can you try to reproduce the error on latest main and bugfix starting from emacs -Q? See https://orgmode.org/manual/Feedback.html#Feedback Best, Ihor
Re: LaTeX letters in Org
On 2022-02-20 at 14:47 +01, Christian Heinrich wrote: FYI, there's also an article on using the scrlttr2 class from KOMA-script (mostly for European/German usage I guess) for letters: https://orgmode.org/worg/exporters/koma-letter-export.html Oh nice, should pay more attention to worg. I had to write a letter today and used that (also I live in Germany so Koma-script works fine for me). I was also surprised to see this not in org-contrib but in the main org tree. What was interesting it how it uses special tags as alternative way to set some special export settings via headlines and their contents, which was useful for multi-line settings like the from- and to-adresses, but I haven't seen anything like that that in any other exporters. Cheers, Michael signature.asc Description: PGP signature
profiling latency in large org-mode buffers (under both main & org-fold feature)
I'm trying to figure out what causes high latency while typing in large
org-mode files. The issue is very clearly a result of my large config
file, but I'm not sure how to track it down with any precision.
My main literate config file is ~/.emacs.d/emacs-init.org, currently 15000
lines, 260 src blocks.
If I create a ~minimal.el~ config like this:
(let* ((all-paths
'("/home/matt/src/org-mode/emacs/site-lisp/org")))
(dolist (p all-paths)
(add-to-list 'load-path p)))
(require 'org)
(find-file "~/.emacs.d/emacs-init.org")
then I do not notice any latency while typing. If I run the profiler while
using the minimal config, the profile looks about like this at a high
level:
1397 71% - command-execute
740 37% - funcall-interactively
718 36% - org-self-insert-command
686 34%+ org-element--cache-after-change
10 0%+ org-fold-core--fix-folded-region
3 0%+ blink-paren-post-self-insert-function
2 0%+ jit-lock-after-change
1 0% org-fold-check-before-invisible-edit--text-properties
9 0% + previous-line
6 0% + minibuffer-complete
3 0% + org-return
3 0% + execute-extended-command
657 33% - byte-code
657 33% - read-extended-command
64 3%- completing-read-default
14 0% + redisplay_internal (C function)
1 0% + timer-event-handler
371 18% - redisplay_internal (C function)
251 12% + jit-lock-function
90 4% + assq
7 0% + substitute-command-keys
3 0% + eval
125 6% + timer-event-handler
69 3% + ...
--
However, if I instead use my fairly extensive main config, latency is high
enough that there's a noticeable delay while typing ordinary words. I see
this regardless of whether I build from main or from Ihor's org-fold
feature branch on github. The profiler overview here is pretty different --
redisplay_internal takes a much higher percentage of the CPU requirement:
3170 56% - redisplay_internal (C function)
693 12% - substitute-command-keys
417 7% + #
59 1% + assq
49 0% + org-in-subtree-not-table-p
36 0% + tab-bar-make-keymap
35 0%and
24 0% + not
16 0%org-at-table-p
13 0% + jit-lock-function
8 0%keymap-canonicalize
7 0% + #
4 0% + funcall
4 0%display-graphic-p
3 0% + #
3 0%file-readable-p
3 0% + table--probe-cell
3 0%table--row-column-insertion-point-p
1486 26% - command-execute
1200 21% - byte-code
1200 21% - read-extended-command
1200 21%- completing-read-default
1200 21% - apply
1200 21% - vertico--advice
475 8% + #
--
I've almost never used the profiler and am not quite sure how I should
proceed to debug this. I realize I can comment out parts of the config one
at a time, but that is not so easy for me to do in my current setup, and I
suppose there are likely to be multiple contributing causes, which I may
not really notice except in the aggregate.
If anyone has suggestions, I would love to hear them!
Thanks,
Matt
Re: profiling latency in large org-mode buffers (under both main & org-fold feature)
i have been dealing with latency also, often in undo-tree. this might
be a dumb suggestion, but is it related to org file size? my files
have not really grown /that/ much but maybe you could bisect one. as
opposed to config.
i am not saying that your org files are too big. just that maybe it
could lead to insights.
On 2/21/22, Matt Price wrote:
> I'm trying to figure out what causes high latency while typing in large
> org-mode files. The issue is very clearly a result of my large config
> file, but I'm not sure how to track it down with any precision.
>
> My main literate config file is ~/.emacs.d/emacs-init.org, currently 15000
> lines, 260 src blocks.
> If I create a ~minimal.el~ config like this:
>
> (let* ((all-paths
> '("/home/matt/src/org-mode/emacs/site-lisp/org")))
> (dolist (p all-paths)
> (add-to-list 'load-path p)))
>
> (require 'org)
> (find-file "~/.emacs.d/emacs-init.org")
>
> then I do not notice any latency while typing. If I run the profiler while
> using the minimal config, the profile looks about like this at a high
> level:
>
> 1397 71% - command-execute
> 740 37% - funcall-interactively
> 718 36% - org-self-insert-command
> 686 34%+ org-element--cache-after-change
> 10 0%+ org-fold-core--fix-folded-region
>3 0%+ blink-paren-post-self-insert-function
>2 0%+ jit-lock-after-change
>1 0%
> org-fold-check-before-invisible-edit--text-properties
>9 0% + previous-line
>6 0% + minibuffer-complete
>3 0% + org-return
>3 0% + execute-extended-command
> 657 33% - byte-code
> 657 33% - read-extended-command
> 64 3%- completing-read-default
> 14 0% + redisplay_internal (C function)
>1 0% + timer-event-handler
> 371 18% - redisplay_internal (C function)
> 251 12% + jit-lock-function
> 90 4% + assq
>7 0% + substitute-command-keys
>3 0% + eval
> 125 6% + timer-event-handler
> 69 3% + ...
>
> --
> However, if I instead use my fairly extensive main config, latency is high
> enough that there's a noticeable delay while typing ordinary words. I see
> this regardless of whether I build from main or from Ihor's org-fold
> feature branch on github. The profiler overview here is pretty different --
> redisplay_internal takes a much higher percentage of the CPU requirement:
>
> 3170 56% - redisplay_internal (C function)
> 693 12% - substitute-command-keys
> 417 7% + #
> 59 1% + assq
> 49 0% + org-in-subtree-not-table-p
> 36 0% + tab-bar-make-keymap
> 35 0%and
> 24 0% + not
> 16 0%org-at-table-p
> 13 0% + jit-lock-function
>8 0%keymap-canonicalize
>7 0% + #
>4 0% + funcall
>4 0%display-graphic-p
>3 0% + #
>3 0%file-readable-p
>3 0% + table--probe-cell
>3 0%table--row-column-insertion-point-p
> 1486 26% - command-execute
> 1200 21% - byte-code
> 1200 21% - read-extended-command
> 1200 21%- completing-read-default
> 1200 21% - apply
> 1200 21% - vertico--advice
> 475 8% + #
>
> --
> I've almost never used the profiler and am not quite sure how I should
> proceed to debug this. I realize I can comment out parts of the config one
> at a time, but that is not so easy for me to do in my current setup, and I
> suppose there are likely to be multiple contributing causes, which I may
> not really notice except in the aggregate.
>
> If anyone has suggestions, I would love to hear them!
>
> Thanks,
>
> Matt
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
More robust CSL-JSON date parsing in oc-basic
Hi all,
I think I've found an opportunity to make oc-basic a bit more resilient
w.r.t. different kinds of CSL-JSON publication date input. I encountered
the following error:
Error (org-mode-hook): Error running hook "org-fancy-priorities-mode"
because: (error Unknown CSL-JSON date format: nil)
(Based on the debugger traceback, what triggered it was citar loading
oc-basic for fontification purposes.)
After a small tweak to oc-basic (see below), the error message got a bit
more informative:
Error (org-mode-hook): Error running hook "org-fancy-priorities-mode"
because: (error Unknown CSL-JSON date format: ((literal . "2009 / 09 /
01 /")))
Based on this, I ended up making the following changes to oc-basic:
--8<>8--
diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index fc71d22fc..de9be40a1 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -178,21 +178,24 @@ Return a hash table with citation references as
keys and fields alist as values.
" and ")))
('issued
;; Date are expressed as an array
- ;; (`date-parts') or a "string (`raw').
- ;; In both cases, extract the year and
- ;; associate it to `year' field, for
- ;; compatibility with BibTeX format.
+ ;; (`date-parts') or a "string (`raw'
+ ;; or `literal'). In both cases,
+ ;; extract the year and associate it
+ ;; to `year' field, for compatibility
+ ;; with BibTeX format.
(let ((date (or (alist-get 'date-parts value)
- (alist-get 'raw value
+ (alist-get 'raw value)
+ (alist-get 'literal value
(cons 'year
(cond
((consp date)
(caar date))
((stringp date)
-(car (split-string date "-")))
+(replace-regexp-in-string
".*?\\([0-9]\\{4\\}\\).*" "\\1" date))
+
(t
(error "Unknown CSL-JSON date
format: %S"
- date))
+ value))
(_
(cons field value
item)
--8<>8--
A few comments, starting from the top:
1. In practice, it looks like string-valued dates can either be tagged
with 'raw or with 'literal. Not sure what the difference is, whether
one is older or deprecated. I just know that my CSL-JSON (produced by
Better BibTeX from Zotero) is full of the latter, and oc-basic didn't
account for this possibility, so I added it.
2. I'm pretty sure the weird date format, "2009 / 09 / 01 /", is not
something I entered manually. My preferred format would be
"2009-09-01", which is what oc-basic currently expects. But with
Zotero, I tend to rely on metadata being filled in automagically, and
it looks like it's the Wild West out there. So I figured a more
robust way to extract the year portion might be to match the first
sequence of 4 digits, instead of splitting the string on - and taking
the car of the resulting list.
Of course, both are just heuristics, both can fail (each in different
ways), and both can result in the entire string being used as the
year. My suggested change is based purely on the fact that the
4-digit heuristic more often does the right thing in my own
collection of bibliography entries.
3. The last change uses value instead of date in the error message,
which makes it more informative, as shown above -- when encountering
a problem, the user gets to see the offending entry, instead of just
nil.
Let me know which of these changes -- if any -- seem acceptable, and
whether they qualify as tinychange, and I'll happily submit a proper
patch :)
Best,
David
Footnote tooltips (an attempt)
Hi all, I think sometimes it would be nice to have tooltips in the footnote references, so I can see the contents of each footnote definition, especially when I'm in a narrowed subtree; so I've tried to write some code. I have achieved a "semi-automatic" solution. It doesn't work bad at all, but I'm not entirely convinced either. With a minor mode the `org-activate-footnote-links' function is overridden, and tooltips content for all footnotes in the document are added or updated after a couple of actions when you finish writing or editing a footnote: `org-edit-src-exit' and `org-mark-ring-goto'. And that's where the automatic part ends. Beyond that, tooltips must be updated/added by calling the `my-org-fn-make-tooltips' function. Here is a short video demo: https://cloud.disroot.org/s/a4gejYc6PSwNWHY I attach the code of my poor man's footnote tooltips. Of course, any comment and/or feedback is appreciated. Best regards, Juan Manuel fn-tooltips.org Description: Lotus Organizer
Re: profiling latency in large org-mode buffers (under both main & org-fold feature)
Matt Price writes: > However, if I instead use my fairly extensive main config, latency is high > enough that there's a noticeable delay while typing ordinary words. I see > this regardless of whether I build from main or from Ihor's org-fold > feature branch on github. The profiler overview here is pretty different -- > redisplay_internal takes a much higher percentage of the CPU requirement: > > 3170 56% - redisplay_internal (C function) > > 1200 21%- completing-read-default > 1200 21% - apply > 1200 21% - vertico--advice > 475 8% + # Judging from the profiler report, you did not collect enough number of CPU samples. I recommend to keep the profiler running for at least 10-30 seconds when trying to profile typing latency. Also, note that running M-x profiler-report second time will _not_ reproduce the previous report, but instead show CPU profiler report between the last invocation of profiler-report and the second one. I recommend to do the following: 1. M-x profiler-stop 2. M-x profiler-start 3. Do typing in the problematic Org file for 10-30 seconds 4. M-x profiler-report (once!) 5. Share the report here > I've almost never used the profiler and am not quite sure how I should > proceed to debug this. I realize I can comment out parts of the config one > at a time, but that is not so easy for me to do in my current setup, and I > suppose there are likely to be multiple contributing causes, which I may > not really notice except in the aggregate. The above steps should be the first thing to try and they will likely reveal the bottleneck. If not, you can go back to genetic bisection. I do not recommend manual commenting/uncommenting parts of you large config. Instead, you can try https://github.com/Malabarba/elisp-bug-hunter. But only if CPU profiling does not reveal anything useful. Best, Ihor
Re: profiling latency in large org-mode buffers (under both main & org-fold feature)
Samuel Wales writes: > i have been dealing with latency also, often in undo-tree. this might > be a dumb suggestion, but is it related to org file size? my files > have not really grown /that/ much but maybe you could bisect one. as > opposed to config. I am wondering if many people in the list experience latency issues. Maybe we can organise an online meeting (jitsi or BBB) and collect the common causes/ do online interactive debugging? Best, Ihor
Re: profiling latency in large org-mode buffers (under both main & org-fold feature)
On Tue, Feb 22, 2022, 12:34 AM Ihor Radchenko wrote: > > I am wondering if many people in the list experience latency issues. > Maybe we can organise an online meeting (jitsi or BBB) and collect the > common causes/ do online interactive debugging? > +1 I have seen few people see this issue on the ox-hugo issue tracker: https://github.com/kaushalmodi/ox-hugo/discussions/551#discussioncomment-2104352
[WISH] Allow to hide the '*Org Help*' in 'org-goto' [9.5.2 (release_9.5.2-13-gdd6486 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello smart people!
Today, I learned about 'org-goto' and started using it. I set the
'org-goto-auto-isearch' variable to 'nil' for better navigation (and
also because I do not have the arrow keys). Then, I took notes on the
'org-goto' keyboard shortcuts that I plan to use. Finally, I decided to
set the 'org-goto-help' variable to 'nil' to hide the help window, but
that resulted in the error:
> org-goto-location: Wrong type argument: stringp, nil
Could we make it so that setting the 'org-goto-help' to 'nil' makes Org
not show the help window for those who do not need it?
Thank you.
Rudy
Emacs : GNU Emacs 29.0.50 (build 7, x86_64-apple-darwin21.2.0, NS
appkit-2113.20 Version 12.1 (Build 21C52))
of 2022-02-15
Package: Org mode version 9.5.2 (release_9.5.2-13-gdd6486 @
/Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)
current state:
==
(setq
org-agenda-prefix-format "* % t% s"
org-link-elisp-confirm-function 'yes-or-no-p
org-agenda-skip-deadline-prewarning-if-scheduled t
org-cite-insert-processor 'citar
org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-agenda-scheduled-leaders '("Scheduled:" "Scheduled %d×:")
org-agenda-custom-commands '(("a" "Agenda"
((agenda ""
((org-agenda-overriding-header "Fortune")
(org-agenda-files nil) (org-agenda-span 1)
(org-agenda-day-face-function
(lambda (_) 'font-lock-comment-face))
(org-agenda-format-date
(lambda (_) (my/fortune-string)))
)
)
(agenda ""
((org-agenda-overriding-header "\nToday")
(org-agenda-start-on-weekday nil)
(org-agenda-span 1)
(org-agenda-format-date
'my/org-agenda-format-date-not-aligned)
(org-agenda-day-face-function
(lambda (_) 'calendar-today))
(org-agenda-skip-function
'(org-agenda-skip-entry-if 'todo 'done))
)
)
(todo "NEXT|NEXT-IN|ON-HOLD"
((org-agenda-overriding-header "\nNext
actions")
(org-agenda-todo-ignore-scheduled 'all)
(org-agenda-todo-ignore-timestamp 'future)
(org-habit-show-habits nil))
)
(agenda ""
((org-agenda-overriding-header "\nTomorrow")
(org-agenda-start-day "+1d") (org-agenda-span
1)
(org-agenda-format-date
'my/org-agenda-format-date-not-aligned)
(org-habit-show-habits-only-for-today nil)
(org-habit-scheduled-past-days 0))
)
(agenda ""
((org-agenda-overriding-header "\nNear future")
(org-agenda-start-day "+2d")
(org-agenda-start-on-weekday nil)
(org-agenda-span 7) (org-habit-show-habits
nil))
)
(todo "WAIT-FOR"
((org-agenda-overriding-header "\nWaiting")))
)
)
)
org-startup-folded 'show2levels
org-babel-after-execute-hook '(org-display-inline-images)
org-agenda-skip-scheduled-if-done t
org-agenda-files '("~/agenda.org" "~/agenda-work.org")
org-capture-templates '(("d" "Default" entry
(file+headline "~/agenda.org" "Captured") "* %?\n%i\n"
:prepend t)
)
org-export-before-parsing-hook '(org-attach-expand-links)
org-link-descriptive nil
org-archive-hook '(org-attach-archive-delete-maybe)
org-cite-follow-processor 'citar
org-file-apps '(("\\.pdf\\'" . emacs) (auto-mode . emacs) (directory . emacs)
("
