[PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
This is the enhancement to `org-narrow-to-subtree' that I suggested back in May [1]. It allows you to choose what level subtree to narrow to. There are two ways to specify the subtree: use repeated C-u's to select "upward" from the current subtree, or use a direct numeric prefix arg to specify the subtree "downward" from level 1. (This is a somewhat unusual prefix argument usage, but it's useful to be able to choose from either direction, and the convenience of using C-u to select upward is quite enormous -- I expect it to be the common case, and it's pretty much the only way I use the feature.) The prefix arg is optional, of course: if you don't pass it, then `org-narrow-to-subtree' behaves the same way it has always behaved. Best regards, -Karl [1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-05/msg00225.html >From bbeca3c5444646685085c134b10f4883812068a0 Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Sat, 30 Nov 2019 01:33:15 -0600 Subject: [PATCH] Use prefix arg to narrow to a specific subtree * lisp/org.el (org-narrow-to-subtree): Take a prefix arg and use it to choose which subtree to narrow to. See thread for context: https://lists.gnu.org/archive/html/emacs-orgmode/2019-05/msg00225.html From: Karl Fogel To: Org Mode Subject: Re: [PROPOSAL] Use prefix arg to control scope \ of org-narrow-to-subtree. Date: Fri, 31 May 2019 02:33:03 -0500 Message-ID: <87y32ncc40@red-bean.com> --- lisp/org.el | 41 ++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 90f222c8b..9b16c59e6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7743,11 +7743,46 @@ If yes, remember the marker and the distance to BEG." (move-marker (car x) (+ beg (cdr x (setq org-markers-to-move nil)) -(defun org-narrow-to-subtree () - "Narrow buffer to the current subtree." - (interactive) +(defun org-narrow-to-subtree (&optional steps) + "Narrow buffer to current subtree or to one specified by prefix arg STEPS. + +Interactively, use the prefix argument in one of two ways to +narrow to a specific subtree: either give one or more C-u's to +specify a subtree that many levels upward from the current +subtree (that is, go up as many levels as the number of C-u's +given -- each C-u counts for one level), or give a strictly +numeric argument to narrow to the subtree that is that many +levels downward from the current top level (level 1) subtree. + +From Lisp, if you want the C-u (upward) behavior, pass STEPS as a +list with the desired number as its sole element. Otherwise, +pass STEPS as a number to get the other (downward) behavior. + +If STEPS would specify a subtree higher than the current level 1 +subtree, then just narrow to that level 1 subtree (in other +words, you can use \"a lot of\" C-u's to narrow quickly to the +current top subtree). If STEPS would specify a subtree deeper +than the current subtree, just narrow to the current subtree." + (interactive "P") (save-excursion (save-match-data + (widen) + (if steps + (if (listp steps) + (progn + (setq steps (car steps)) + (when (< steps 0) + (error "Argument cannot be negative")) + (setq steps (round (log steps 4 + (when (< steps 0) ; awkward duplication, but hard to avoid + (error "Argument cannot be negative")) + (let ((cur-level (org-outline-level))) + (setq steps (max (- cur-level steps) 0 + (setq steps 0)) + (while (> steps 0) + (if (org-up-heading-safe) + (setq steps (1- steps)) + (setq steps 0))) (org-with-limited-levels (narrow-to-region (progn (org-back-to-heading t) (point)) -- 2.24.0
Re: [PATCH] ob-java.el: Add header argument to pass command line args
Nicolas Goaziou writes: >> Any hope of this super tiny patch being applied? It addresses the >> problem I brought up in another thread: it is currently not possible >> to pass command line arguments to a java program. > > Org 9.3 is feature frozen for the time being. Do you think this > qualifies as a bugfix or as a new feature? More of a new feature, I guess. > In the latter case, could you rebase it on top of "next" branch and > add an entry in ORG-NEWS, under "Org 9.4" section? I did my best; see attachments. There was no 9.4 section in ORG-NEWS, so I added my entry under "Version Next". Are these ok? Jarmo >From 5089053f4f3f916dfbdab009d28b16ffac6f9055 Mon Sep 17 00:00:00 2001 From: Jarmo Hurri Date: Wed, 6 Nov 2019 12:21:16 +0200 Subject: [PATCH 1/2] ob-java.el: Add header argument to pass command line args. * lisp/ob-java.el (org-babel-execute:java): Handle new header argument `:cmdargs` and pass its value as the last element in call to java. --- lisp/ob-java.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ob-java.el b/lisp/ob-java.el index b055f85e5..80308ec32 100644 --- a/lisp/ob-java.el +++ b/lisp/ob-java.el @@ -58,6 +58,7 @@ parameters may be used, like javac -verbose" (src-file (concat classname ".java")) (cmpflag (or (cdr (assq :cmpflag params)) "")) (cmdline (or (cdr (assq :cmdline params)) "")) + (cmdargs (or (cdr (assq :cmdargs params)) "")) (full-body (org-babel-expand-body:generic body params))) (with-temp-file src-file (insert full-body)) (org-babel-eval @@ -66,7 +67,7 @@ parameters may be used, like javac -verbose" (unless (or (not packagename) (file-exists-p packagename)) (make-directory packagename 'parents)) (let ((results (org-babel-eval (concat org-babel-java-command - " " cmdline " " classname) ""))) + " " cmdline " " classname " " cmdargs) ""))) (org-babel-reassemble-table (org-babel-result-cond (cdr (assq :result-params params)) (org-babel-read results) -- 2.21.0 >From 033f455399d0821d818ef6ff1c01036c04873ddb Mon Sep 17 00:00:00 2001 From: Jarmo Hurri Date: Sun, 1 Dec 2019 12:26:55 +0200 Subject: [PATCH 2/2] Mention header argument to pass command arguments to Java blocks in ORG-NEWS * etc/ORG-NEWS: Mention header argument :cmdargs for Java code blocks. --- etc/ORG-NEWS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 689a07871..ac3d1517f 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -19,6 +19,9 @@ just as if it was at outline level 0. Inheritance for properties will work also for this level. In other words; defining things in a property drawer before the first headline will make them "inheritable" for all headlines. +*** New header argument to pass Java command line arguments +Babel Java blocks recognize header argument =:cmdargs= and pass its +value in call to =java=. * Version 9.3 -- 2.21.0
Re: org-mime-htmlize and signature
On Saturday, 30 Nov 2019 at 18:37, Pankaj Jangid wrote: > It converts the text in the message buffer into multipart message. But > the conversion doesn't work well at the point of signature. For these cases, I usually put a colon at the start of each line of the signature which htmlize then converts as preformatted text. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-572-gbe7e88
Re: is this a known issue in clocktable output?
Soubzriquet writes: >> [...] >> > odd issue with using "day" steps where the date is getting offset >> > sometimes. >> > >> > I saw the issue with 26.1, was not fixed by updating to current >> > environment with an empty init.el on OS X: >> [...] >> >> > * Day 1 >> > :LOGBOOK: >> > CLOCK: [2019-11-01 Fri 10:00]--[2019-11-01 Fri 11:00] => 1:00 >> > :END: >> > * Day 2 >> > :LOGBOOK: >> > CLOCK: [2019-11-02 Sat 10:00]--[2019-11-02 Sat 12:00] => 2:00 >> > :END: >> > * Day 3 >> > :LOGBOOK: >> > CLOCK: [2019-11-03 Sun 10:00]--[2019-11-03 Sun 13:00] => 3:00 >> > :END: >> > * Day 4 >> > :LOGBOOK: >> > CLOCK: [2019-11-04 Mon 10:00]--[2019-11-04 Mon 14:00] => 4:00 >> > :END: >> > * Day 5 >> > :LOGBOOK: >> > CLOCK: [2019-11-05 Tue 10:00]--[2019-11-05 Tue 15:00] => 5:00 >> > :END: >> > * Day 6 >> > :LOGBOOK: >> > CLOCK: [2019-11-06 Wed 10:00]--[2019-11-06 Wed 16:00] => 6:00 >> > :END: >> > >> > #+BEGIN: clocktable :scope file :maxlevel 2 :block thismonth :step day >> :stepskip0 t >> > >> > Daily report: [2019-11-01 Fri] >> > | Headline | Time | >> > |--+| >> > | *Total time* | *1:00* | >> > |--+| >> > | Day 1| 1:00 | >> > >> > Daily report: [2019-11-02 Sat] >> > | Headline | Time | >> > |--+| >> > | *Total time* | *2:00* | >> > |--+| >> > | Day 2| 2:00 | >> > >> > Daily report: [2019-11-03 Sun] >> > | Headline | Time | >> > |--+| >> > | *Total time* | *3:00* | >> > |--+| >> > | Day 3| 3:00 | >> > >> > Daily report: [2019-11-03 Sun] >> > | Headline | Time | >> > |--+| >> > | *Total time* | *4:00* | >> > |--+| >> > | Day 4| 4:00 | >> > >> > Daily report: [2019-11-04 Mon] >> > | Headline | Time | >> > |--+| >> > | *Total time* | *5:00* | >> > |--+| >> > | Day 5| 5:00 | >> > >> > Daily report: [2019-11-05 Tue] >> > | Headline | Time | >> > |--+| >> > | *Total time* | *6:00* | >> > |--+| >> > | Day 6| 6:00 | >> > >> > #+END: >> >> I can not reproduce this behavior. > Hi, sorry I was not more clear - the issue occurs also with emacs -Q or > with empty init.el on my system. Okay, thanks. I think I'm at the end of my abilities to investigate the issue further. I suggest you dig a little deeper for better understanding. E.g.: - Try make the example of failure as small as you can. - Check with a newer version of Org. - Debug the issue. Possibly someone else can confirm the issue. HTH, Marco
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
Karl Fogel writes: > This is the enhancement to `org-narrow-to-subtree' that I suggested back in > May [1]. > > It allows you to choose what level subtree to narrow to. There are > two ways to specify the subtree: use repeated C-u's to select "upward" > from the current subtree, or use a direct numeric prefix arg to > specify the subtree "downward" from level 1. (This is a somewhat > unusual prefix argument usage, but it's useful to be able to choose > from either direction, and the convenience of using C-u to select > upward is quite enormous -- I expect it to be the common case, and > it's pretty much the only way I use the feature.) > > The prefix arg is optional, of course: if you don't pass it, then > `org-narrow-to-subtree' behaves the same way it has always behaved. +1 I think your enhancement is great and worth a news entry. What about pushing your code if nobody objects within one week? Ciao, Marco
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 01 Dec 2019, Marco Wahl wrote: >+1 > >I think your enhancement is great and worth a news entry. What about >pushing your code if nobody objects within one week? Thanks, Marco; I'm glad you like it. I'll wait a week and then push (unless there's discussion, in which case we'll see what the outcome of the discussion is first, of course). I just created a "kfogel" account at https://code.orgmode.org/ and uploaded my SSH key. Should I mail Bastien about push access, or is posting here enough? Regarding a news entry: that means the 9.3 section of etc/ORG-NEWS, right? I will add a news entry to the commit at push time. Best regards, -Karl
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
Hi Karl, >>I think your enhancement is great and worth a news entry. What about >>pushing your code if nobody objects within one week? > > Thanks, Marco; I'm glad you like it. I'll wait a week and then push > (unless there's discussion, in which case we'll see what the outcome > of the discussion is first, of course). This sounds right to me. > I just created a "kfogel" account at https://code.orgmode.org/ and > uploaded my SSH key. Should I mail Bastien about push access, or is > posting here enough? I guess it's a good idea to write to Bastien explicitly. > Regarding a news entry: that means the 9.3 section of etc/ORG-NEWS, > right? I will add a news entry to the commit at push time. Great! Thanks for asking about the version. AFAICT there is a feature freeze right now for version 9.3. This means you would commit to the 'next' branch which shall be the next master branch after the release. And also you would add the news entry in section [Version Next] in etc/ORG-NEWS. Ciao, Marco
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 01 Dec 2019, Marco Wahl wrote: >I guess it's a good idea to write to Bastien explicitly. I will do so. >Thanks for asking about the version. AFAICT there is a feature freeze >right now for version 9.3. This means you would commit to the 'next' >branch which shall be the next master branch after the release. And >also you would add the news entry in section [Version Next] in >etc/ORG-NEWS. Ah, okay. Thanks for letting me know; I'll do all that. Best regards, -Karl
Custom time stamps in column view
Hello all, I use column view quite a lot. Very useful, especially for editing properties. I also use it for task management, having moved to Marcin Swieczkowski's approach [1]. For managing my tasks, the column view I have defined includes scheduled and deadline dates. I would like to be able to use a custom time stamp display. That works for normal view but not in the column view. I guess I'm making a feature request: to be able to use custom time display in column views. Would this be possible? (or, knowing me, it might already be possible so would somebody tell me how?) Thanks, eric Footnotes: [1] https://media.emacsconf.org/2019/09.html -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-572-gbe7e88
[PATCH] Add customization to fontify TODO headlines
This adds a feature similar to the org-fontify-done-headline, but instead for the TODO headlines. This is enabled with the boolean customization org-fontify-todo-headline and can be themed via the face org-headline-todo. I was missing this when I wanted to distinguish more clearly between the TODO headlines and the other headlines (more so than the highlighted TODO keyword(s)). Hope someone else finds this useful. Best regards, Terje Larsen >From 57dd1fca737794f4c20d439d1fbf288511b1e44f Mon Sep 17 00:00:00 2001 From: Terje Larsen Date: Sun, 1 Dec 2019 20:20:55 +0100 Subject: [PATCH] org: Add customization to fontify TODO headlines * lisp/org (org-fontify-todo-headline): Add new boolean customization to toggle this behavior. * lisp/org (org-set-font-lock-defaults): Apply face org-headline-todo to lines starting with keywords in org-not-done-keywords. * lisp/org-faces (org-headline-todo): Add new face to customize look of todo headlines. --- etc/ORG-NEWS | 5 + lisp/org-faces.el | 9 + lisp/org.el | 18 ++ 3 files changed, 32 insertions(+) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 689a07871..872cebf76 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -20,6 +20,11 @@ work also for this level. In other words; defining things in a property drawer before the first headline will make them "inheritable" for all headlines. +*** Fontify whole TODO headlines +This feature is the same as =org-fontify-done-headline=, but for TODO +headlines instead. This allows you to distinguish TODO headlines from +normal headlines. The face can be customized via =org-headline-todo=. + * Version 9.3 ** Incompatible changes diff --git a/lisp/org-faces.el b/lisp/org-faces.el index a97d4dc4a..416f49b52 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -243,6 +243,15 @@ is of course immediately visible, but for example a passed deadline is of the frame, for example." :group 'org-faces) +(defface org-headline-todo ;Copied from `font-lock-string-face' + 'class color) (min-colors 16) (background light)) (:foreground "Red4")) +(((class color) (min-colors 16) (background dark)) (:foreground "Pink2")) +(((class color) (min-colors 8) (background light)) (:bold t))) + "Face used to indicate that a headline is marked as TODO. +This face is only used if `org-fontify-todo-headline' is set. If applies +to the part of the headline after the TODO keyword." + :group 'org-faces) + (defface org-headline-done ;Copied from `font-lock-string-face' 'class color) (min-colors 16) (background light)) (:foreground "RosyBrown")) (((class color) (min-colors 16) (background dark)) (:foreground "LightSalmon")) diff --git a/lisp/org.el b/lisp/org.el index 20c263f74..53bc47641 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3686,6 +3686,15 @@ hide them with `org-toggle-custom-properties-visibility'." :version "24.3" :type '(repeat (string :tag "Property Name"))) +(defcustom org-fontify-todo-headline nil + "Non-nil means change the face of a headline if it is marked as TODO. +Normally, only the TODO/DONE keyword indicates the state of a headline. +When this is non-nil, the headline after the keyword is set to the +`org-headline-todo' as an additional indication." + :group 'org-appearance + :package-version '(Org . "9.4") + :type 'boolean) + (defcustom org-fontify-done-headline nil "Non-nil means change the face of a headline if it is marked DONE. Normally, only the TODO/DONE keyword indicates the state of a headline. @@ -5652,6 +5661,15 @@ needs to be inserted at a specific position in the font-lock sequence.") (list (format org-heading-keyword-regexp-format org-todo-regexp) '(2 (org-get-todo-face 2) t)) + ;; TODO + (if org-fontify-todo-headline + (list (format org-heading-keyword-regexp-format + (concat + "\\(?:" + (mapconcat 'regexp-quote org-not-done-keywords "\\|") + "\\)")) + '(2 'org-headline-todo t)) + nil) ;; DONE (if org-fontify-done-headline (list (format org-heading-keyword-regexp-format -- 2.24.0
Support for something like org-image-max-width
There is already org-image-actual-width but the problem with that one is that images that have quite small width, but are tall will be scaled and become very tall. I think it would make sense to introduce something like org-image-max-width, which would scale images that are larger than this width, but leave images within this width alone. Another interesting thing would be to be able to adjust the max-width to the width of the buffer, but not sure how well that will play in all cases and how complex that would be. Any thoughts on this? Best regards, Terje Larsen
[PATCH] Derive non-default start value for ordered list
Hi there,
currently, we have to write the following to continue an ordered
list from a value different from 1:
42. [@42] Answer
43. Question?
The requirement to type redundant information with the @-syntax
always struck me as odd. For my export backend org-re-reveal, I
recently received a request to export lists without @-syntax to
their “correct” start values [1].
Before working on my backend, I’d like to ask for feedback: Why was
the @-syntax introduced? Of what non-obvious effects should I be
aware?
What do you think about the attached patch that allows to omit the
@-syntax? Controlled by the new variable
org-list-use-first-bullet-as-non-standard-counter, the code assigns
a counter value to the first list item from its bullet string if the
item
1. does not specify a counter itself,
2. has an alphanumeric bullet, and
3. does not have a default start value (1, a, A).
I hacked this as postprocessing step on the list’s struct. Maybe an
Org expert could suggest how to do this in one pass?
Best wishes
Jens
P.S. I did not work on documentation yet as I’m not sure that this
change is acceptable.
[1] https://gitlab.com/oer/org-re-reveal/merge_requests/27
>From 2eea43d84687259633f847bd17883e5fe578b6bc Mon Sep 17 00:00:00 2001
From: Jens Lechtenboerger
Date: Sun, 1 Dec 2019 21:17:43 +0100
Subject: [PATCH] Use bullet as non-standard counter
* lisp/org-list.el: New variable
org-list-use-first-bullet-as-non-standard-counter and new function
org-list-struct-maybe-add-counters to assign counters from bullets
that indicate non-standard start values.
(org-list-struct): Use new variable and function.
* lisp/org-element.el (org-element-item-parser): Use new variable and
mirror behavior of org-list.el.
---
lisp/org-element.el | 19 ++-
lisp/org-list.el| 33 -
2 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 56b3cc413..80b7cab99 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1269,6 +1269,8 @@ Assume point is at the beginning of the item."
(beginning-of-line)
(looking-at org-list-full-item-re)
(let* ((begin (point))
+ (prevs (org-list-prevs-alist struct))
+ (prev-item (org-list-get-prev-item begin struct prevs))
(bullet (match-string-no-properties 1))
(checkbox (let ((box (match-string 3)))
(cond ((equal "[ ]" box) 'off)
@@ -1277,7 +1279,22 @@ Assume point is at the beginning of the item."
(counter (let ((c (match-string 2)))
(save-match-data
(cond
- ((not c) nil)
+ ((not c)
+ (and
+ org-list-use-first-bullet-as-non-standard-counter
+ ;; As in org-list-struct-maybe-add-counters,
+ ;; assign non-standard counter from bullet of
+ ;; first list item. To exclude "A", check range
+ ;; from "B".
+ (not prev-item)
+ (or (and (string-match "[B-Zb-z]" bullet)
+(- (string-to-char
+ (upcase (match-string 0 bullet)))
+ 64))
+ (and (string-match "[0-9]+" bullet)
+(string< "1" (match-string 0 bullet))
+(string-to-number
+ (match-string 0 bullet))
((string-match "[A-Za-z]" c)
(- (string-to-char (upcase (match-string 0 c)))
64))
diff --git a/lisp/org-list.el b/lisp/org-list.el
index c4aef32fc..fe8742f42 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -336,6 +336,14 @@ clearly distinguish sub-items in a list."
:version "24.1"
:type 'integer)
+(defcustom org-list-use-first-bullet-as-non-standard-counter nil
+ "Non-nil means to use first bullet of an ordered list as counter.
+Then, you can start an ordered list with \"42. Answer\" instead of
+\"42. [@42] Answer\"."
+ :group 'org-plain-lists
+ :package-version '(Org . "9.3")
+ :type 'boolean)
+
(defvar org-list-forbidden-blocks '("example" "verse" "src" "export")
"Names of blocks where lists are not allowed.
Names must be in lower case.")
@@ -731,7 +739,30 @@ Assume point is at an item."
;; 3. Associate each item to its end position.
(org-list-struct-assoc-end struct end-lst)
;; 4. Return STRUCT
- struct)))
+ (if org-list-use-first-bullet-as-non-standard-counter
+ (org-list-struct-maybe-add-counters struct)
+struct
+
+(defun org-list-struct-maybe-add-counters (struct)
+ "Maybe add counters to first list items of STRUCT.
+For the first list items in STRUCT (those without previous item) that
+1. do not specify a counter,
+2. has an alphanumeric bullet, and
+3. do not have a default start value (1, a, A),
+set the counter to the item's bullet."
+ (let ((prevs (org-list-prevs-alist struct)))
+(dolist (item struct)
+ (let ((prev-item (org-list-get-prev-item (nth 0 item) struct prevs)))
+(unless prev-item
+ (let ((key (nth 0 item))
+
Re: [PATCH] Derive non-default start value for ordered list
i think it might be partlly a question of whether these numbers are fixed things that refer to fixed items [like referring to sections in a law that is not in the document] vs. being used to continue lists. they are both legitimate uses. in the first case, the @ syntax makes sense to me, because it specifies a fixed alphanumber. yes i made that word up. some exporters assume the numbers in the org source list don't matter and start from 1 or the @ in the exported text. so your solution would be anomalous. and i'm used to exporters doing that so it feels strange to me to rely on the org text. i view that as potentially changing. what should occur if you do something that renumbers it? in the second case, the @ syntax and your solution both seem brittle to me. you might add to the first list. i think there can be a third solution that would be less brittle. just as a brainstorm, consider the common case of continued lists like vvv 1. asdf 2. <> asdf a paragraph. 3. [@asdf-list-end] asdf ^^^ this solution still fails if you have the first list in a separate file. therefore i propose org id to solve that. for this, we could invoke the org id mechanism, or use id markers, which is an old, unimplemented idea that can substitute for a bunch of syntax with a consistent syntax. but in any case the above illustrates a less brittle solution than @ numbers and using the existing number. does that make any sense? just a brainstorm, not to be taken too seriously if you think it's all wrong. On 12/1/19, Jens Lechtenboerger wrote: > Hi there, > > currently, we have to write the following to continue an ordered > list from a value different from 1: > > 42. [@42] Answer > 43. Question? > > The requirement to type redundant information with the @-syntax > always struck me as odd. For my export backend org-re-reveal, I > recently received a request to export lists without @-syntax to > their “correct” start values [1]. > > Before working on my backend, I’d like to ask for feedback: Why was > the @-syntax introduced? Of what non-obvious effects should I be > aware? > > What do you think about the attached patch that allows to omit the > @-syntax? Controlled by the new variable > org-list-use-first-bullet-as-non-standard-counter, the code assigns > a counter value to the first list item from its bullet string if the > item > 1. does not specify a counter itself, > 2. has an alphanumeric bullet, and > 3. does not have a default start value (1, a, A). > > I hacked this as postprocessing step on the list’s struct. Maybe an > Org expert could suggest how to do this in one pass? > > Best wishes > Jens > > P.S. I did not work on documentation yet as I’m not sure that this > change is acceptable. > > [1] https://gitlab.com/oer/org-re-reveal/merge_requests/27 > > -- 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: [PATCH] Derive non-default start value for ordered list
[note: id markers use org ids.] On 12/1/19, Samuel Wales wrote: > i think it might be partlly a question of whether these numbers are > fixed things that refer to fixed items [like referring to sections in > a law that is not in the document] vs. being used to continue lists. > > they are both legitimate uses. in the first case, the @ syntax makes > sense to me, because it specifies a fixed alphanumber. yes i made > that word up. > > some exporters assume the numbers in the org source list don't matter > and start from 1 or the @ in the exported text. so your solution > would be anomalous. > > and i'm used to exporters doing that so it feels strange to me to rely > on the org text. i view that as potentially changing. what should > occur if you do something that renumbers it? > > > in the second case, the @ syntax and your solution both seem brittle > to me. you might add to the first list. > > > i think there can be a third solution that would be less brittle. > > just as a brainstorm, consider the common case of continued lists like > > vvv > 1. asdf > 2. <> asdf > > a paragraph. > > 3. [@asdf-list-end] asdf > ^^^ > > this solution still fails if you have the first list in a separate > file. therefore i propose org id to solve that. > > for this, we could invoke the org id mechanism, or use id markers, > which is an old, unimplemented idea that can substitute for a bunch of > syntax with a consistent syntax. > > but in any case the above illustrates a less brittle solution than @ > numbers and using the existing number. > > does that make any sense? > > just a brainstorm, not to be taken too seriously if you think it's all > wrong. > > > On 12/1/19, Jens Lechtenboerger wrote: >> Hi there, >> >> currently, we have to write the following to continue an ordered >> list from a value different from 1: >> >> 42. [@42] Answer >> 43. Question? >> >> The requirement to type redundant information with the @-syntax >> always struck me as odd. For my export backend org-re-reveal, I >> recently received a request to export lists without @-syntax to >> their “correct” start values [1]. >> >> Before working on my backend, I’d like to ask for feedback: Why was >> the @-syntax introduced? Of what non-obvious effects should I be >> aware? >> >> What do you think about the attached patch that allows to omit the >> @-syntax? Controlled by the new variable >> org-list-use-first-bullet-as-non-standard-counter, the code assigns >> a counter value to the first list item from its bullet string if the >> item >> 1. does not specify a counter itself, >> 2. has an alphanumeric bullet, and >> 3. does not have a default start value (1, a, A). >> >> I hacked this as postprocessing step on the list’s struct. Maybe an >> Org expert could suggest how to do this in one pass? >> >> Best wishes >> Jens >> >> P.S. I did not work on documentation yet as I’m not sure that this >> change is acceptable. >> >> [1] https://gitlab.com/oer/org-re-reveal/merge_requests/27 >> >> > > > -- > 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. > -- 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.
Customize listings per language?
I often have several different babel languages in the same file. I'd
like to be able make them easily distinguished by language (such as
having a different background or shadow).
As far as I can tell, the listings package doesn't let me override
settings by language.
The best solution I've so far is to precede each block with a
directive, such as:
#+ATTR_LATEX: :options rulesepcolor=\color{green}
#+begin_src elisp
Any suggestions for a less error-prone solution?
Kind regards,
Mike
Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]
I have one scheduled item like the following:
* test
<2019-12-05 Thu 23:00-29:00>
This kind of item fails to be parsed by agenda because of incorrect
treatment of 23:00-29:00 time interval
Specifically, calling
(org-agenda-format-item nil #("test" 0 3 (face org-level-1 org-category
"schedule" fontified t)) " " "schedule" nil #("<2019-12-02 Mon 23:00-29:00>"
... ) ...)
yields (org-get-time-of-day "29:00" 'string t) -> "+5:00", which is then
passed to (org-duration-to-minutes "+5:00"), resulting in error.
Regards,
Ihor
Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0)
of 2019-11-25
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/home/yantar92/.emacs.d/straight/build/org/)
Re: Org export to HTML with encrypted information ??
w...@mm.st writes:
> Hi,
> Here's a simpler flow. See if it would support your use case:
>
> Modern PDF readers support password
> encryption. org-latex-export-to-pdf, then encrypt the file and share
> it with your family. If you want to keep it offline, give them USB
> drives. It's not too late to get black Friday deals on the 2.0 sticks.
>
> Write the password on a sticky note and stick it on your fridge.
>
> If you're worried about the integrity of the org file on your own
> computer, make it a .gpg file instead, and stick something like:
>
> # -*- mode:org; epa-file-encrypt-to: ("y...@email.com") -*-
>
> at the top.
This is an interesting idea that I'm considering, but it kind of assumes
that the data is (mostly) static. Updating the information gets a
little tedious, but it is doable. Encryption into the cloud makes it a
little easier to keep it up-to-date for the family as I change the data.
--
David
Re: Org export to HTML with encrypted information ??
Colin Baxter writes: >> David Masterson writes: > > > My use-case is this: I'd like to use Org to write up *all* the > > information about my family life (so to speak) including medical > > histories of my family, issues with the house, bank accounts, > > financial information, etc., so that my family has all the > > I would strongly advise against including any financial or medical > information. All encryption is breakable given adequate resources. I > suggest that you would be providing sufficient motivation for someone > to garner those resources. An issue I am concerned about. I'm considering the tradeoffs and, ultimately, may go with a USB key mechanism, but it would make the process flow more tedious. -- David
Re: [PATCH] Derive non-default start value for ordered list
Hello, Jens Lechtenboerger writes: > currently, we have to write the following to continue an ordered > list from a value different from 1: > > 42. [@42] Answer > 43. Question? > > The requirement to type redundant information with the @-syntax > always struck me as odd. For my export backend org-re-reveal, I > recently received a request to export lists without @-syntax to > their “correct” start values [1]. > > Before working on my backend, I’d like to ask for feedback: Why was > the @-syntax introduced? Of what non-obvious effects should I be > aware? > > What do you think about the attached patch that allows to omit the > @-syntax? Controlled by the new variable > org-list-use-first-bullet-as-non-standard-counter, the code assigns > a counter value to the first list item from its bullet string if the > item > 1. does not specify a counter itself, > 2. has an alphanumeric bullet, and > 3. does not have a default start value (1, a, A). I think the current situation is better. It works, as advertised, and it allows you to re-number any item in the list, not necessarily the first one. Of course, it may be less "elegant", but the overhead is negligible, and, as a data point, I'd rather have continuation lists more visible than not, as it could create confusion in the document. I do not know about org-re-reveal, but included exporters do not display the [@xxx] part. However, they use its value to start lists at an appropriate number, if technically possible. I suggest org-re-reveal to do the same if that's not the case. Regards, -- Nicolas Goaziou
