[O] Subject: Bug: Confusing documentation for org-complete-tags-always-offer-all-agenda-tags [9.1.14 (9.1.14-1-g4931fc-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20180917/)]

amically (there are none)." That aside, the wording of the second sentence could be clearer. My humble suggestion: "If non-nil, always offer completion for all tags of all agenda files. Setting this variable locally allows for dynamic generation of tag completions in capture buffers.&q

[O] Bug: Can't set org-agenda-follow-indirect in custom agenda command .2 (9.2-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20181230/)]

I'm trying to create a custom agenda command that starts in follow-mode and follows indirectly. Starting with follow mode works fine, but org-agenda-follow-indirect is nil in the resulting org agenda buffer. Minimal Working Example: - save the following org txt as a local file - evaluate the src b

[O] Bug: Typo in org-archive-subtree comment [9.2.2 (9.2.2-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20190304/)]

Just a small typo in the body of org-archive-subtree: ";; Save all relevant TODO keyword-relatex variables" s/relatex/related

Bug: org-capture-get-template can't use a lambda for template function. [9.2.6 (9.2.6-7-g634880-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20191118/)]

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. -

Bug: org-mks case insensitive search breaks org-capture-templates groups [9.3.1 (release_9.3.1-108-gebf8b3 @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

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. -

Bug: org-highest-priority not defined [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

After updating Org, I'm hitting errors for an undefined `org-highest-priority'. I see that this is an alias for `org-priority-highest', but describe-function (and I'm not sure why it's describe-function vs describe-variable) dutifully reports: org-highest-priority is an alias for ‘org-priorit

Re: Bug: org-highest-priority not defined [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

Actually, on closer inspection. Shouldn't: (defalias 'org-highest-priority 'org-priority-highest) be (defvaralias ...)? On Sat, Feb 29, 2020 at 8:09 PM No Wayman wrote: > After updating Org, I'm hitting errors for an undefined > `org-highest-priority'. > I

Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

The logic for saving the archive buffer in org-archive-subtree does not consider the (default) value of 'from-org for org-archive-subtree-save-file-p. #+begin_src emacs-lisp ;; Save and kill the buffer, if it is not the same ;; buffer and depending on `org-archive-subtree-save-file-p' (unle

Re: Bug: org-highest-priority not defined [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

x27;org-priority-default) (defcustom org-priority-default ?B "The default priority of TODO items. This is the priority an item gets if no explicit priority is given. On Sat, Feb 29, 2020 at 11:35 PM No Wayman wrote: > Actually, on closer inspection. Shouldn't: > > (defalia

[BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

The attached patch addresses org-src.el's checkdoc warnings spare the following (IMO spurious) warnings: >158 0 notee-f-cLisp symbol ‘split-window-below’ >should appear in quotes split-window-below is a value used in org-src-window-setup (along with split-window-righ

Re: Visibility cycling with inline tasks 2

I can confirm the issue you've outlined on latest 'main'. To me it looks like the problem is in `org-inline-hide-tasks'. I don't use inline tasks, so I'm not sure what the exact expected behavior is, but that function uses a `while' during `org-cycle-hook' to iterate through all of the headings

Re: Visibility cycling with inline tasks 2

Ihor Radchenko writes: Your patch will fail with the following counterexample (when there is a subheading containing an inlinetask inside current heading): I wasn't really sure what the intended behavior is, but that makes sense. I propose an alternative patch. See the attached. Have

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: Hi, No Wayman writes: The attached patch I don't see a patch, can you resend it? Apologies. Resent. >From e5d1c6cc231363e20b378e082236af44ac717ccc Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Thu, 30 Sep 2021 16:07:15 -0400 Subject: [PATCH] org-src

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: Thanks -- it does not apply against the main branch, can you rebase and resend it? Certainly. See attached. >From 4971ceb26a1fb138f4eeddc1a569b5c4dd3f1859 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Thu, 30 Sep 2021 16:07:15 -0400 Subject: [PATCH] org-src.el: Fix

[PATCH] org-attach: Fix checkdoc warnings

See attached. >From 477f05274d2de75fc6d4761e6e6089f46e024f4e Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Thu, 30 Sep 2021 16:07:15 -0400 Subject: [PATCH] org-attach.el: Fix checkdoc warnings * org-attach.el: Fix checkdoc warnings. --- lisp/org-attach.el | 41 +---

[BUG] [PATCH] org-archive.el: Fix checkdoc warnings [9.5 (9.5-g477f05 @ /home/n/.emacs.d/straight/build/org/)]

See Attached. >From e995d2ed668edd9f29e9a8aeaf39bb0eb039e856 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Thu, 30 Sep 2021 16:07:15 -0400 Subject: [PATCH] org-archive.el: Fix checkdoc warnings * org-archive.el: Fix checkdoc warnings. --- lisp/org-archive.el | 7 --- 1 file change

Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

Confirmed with the following, simpler, test case: Yodel[1] Report 2021-10-05 22:07:33 === --8<---cut here---start->8--- (yodel :user-dir "org-save-all-org-buffers" :packages* org :formatter yodel-format-as-mailing-list-messag

Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

Your analysis is correct. I looked into this a couple days ago. See the following message for an explanation and a patch (testing appreciated): https://list.orgmode.org/87zgrmc2rg@gmail.com/T/#m9888bc09d77d7bba70ba99671aca72446c4d41b9

[BUG] org-element-cache-map calls native-comp-available-p without checking if it is bound first [9.5 (9.5-gf5faff @ /home/n/.emacs.d/straight/build/org/)]

See: https://www.reddit.com/r/emacs/comments/qil2qh/symbols_function_definition_is_void/ For context: (and (symbolp func) (native-comp-available-p) (fboundp 'subr-native-elisp-p) The check could be wrapped in a function to prevent this in the future. e.g. (defun org-native-com

Re: bug#53393: 29.0.50; org mode timestamp C-c C-c not updating day of week

From: "Bruce E. Robertson" Date: Tue, 18 Jan 2022 10:36:22 -0800 emacs -Q test.org cursor to "CLOCK:" line, C-c C-c total time updates but day of week does not change contents of test.org -- * heading :LOGBOOK: CLOCK: [2022-01-17 Tue 10:29]--[2022-01-19 Tue 10:29] => 48:00 :END: -- t

Re: bug#53393: 29.0.50; org mode timestamp C-c C-c not updating day of week

It looks like the correction of the day name in timestamps is hardcoded in `org-ctrl-c-ctrl-c': ((or `timestamp (and `planning (guard (org-at-timestamp-p 'lax (org-timestamp-change 0 'day)) `org-clock-update-time-maybe' uses a regexp to match the start and end times and ha

Re: [PATCH] lisp/org-capture.el: Add hook & hook options to org-capture (Valentin Herrmann)

I've implemented what you're proposing here (and much more) in a package you may find useful a couple years ago. I pitched adopting some of the ideas into org-mode proper and was willing to do the work. My proposal was met with enthusiastic silence: https://www.github.com/progfolio/doct -

Re: [PATCH] lisp/org-capture.el: Add hook & hook options to org-capture (Valentin Herrmann)

Ihor Radchenko writes: No Wayman writes: I've implemented what you're proposing here (and much more) in a package you may find useful a couple years ago. I pitched adopting some of the ideas into org-mode proper and was willing to do the work. My proposal was met with en

Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)

Nicolas Goaziou writes: The fact that we need a tool like "doct" to write templates in a compact form may be a sign that the data type is not good enough. Actually it sounds like a failure somehow. Agreed. That's why I wrote doct in the first place. As others have expressed, there's far t

[Patch] Document org-capture-templates entry type default strings

I've included the default entry type strings for each entry type in org-capture-tempalte's docstring. Made a couple clarifying edits as well. IMO this is better than having the user hunt for the defaults in the source or experimenting by creating each type of template: diff --git a/lisp/or

Bug: org-archive-subtree-save-file-p results in data loss [9.3.6 (release_9.3.6-432-g73bd24 @ /home/n/.emacs.d/straight/build/org/)]

I'm bumping this because it's bitten me several times. The default value of 'from-org is not covered in the saving logic in org-archive-subtree: https://lists.gnu.org/archive/html/emacs-orgmode/2020-03/msg9.html I keep notes in Org for development projects. Archiving removes the node f

Re: Emacs-orgmode Digest, Vol 170, Issue 5

Someone on #org-mode (sorry, I cannot remember the nickname) reported that ".+" repeater style was not handling properly (not handling at all, actually) hours spans. As a reminder, ".+" means "repeat, starting from today as the base date". With hours, it seems logical to "repeat, starting f

Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

Kyle Meyer writes: Based on the history above, I believe the main purpose is to give users a way to reverse the "no saving" behavior made in 63f6e851b (Do not save target buffer after archiving subtree, 2017-11-25). I'm _guessing_ that, on top of that, the idea adding a from-agenda value w

Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

Kyle Meyer writes: Thanks for the suggestion. The code is somewhat oddly formatted, at least on my end. Could you send a proper git-format-patch output to this thread (either via git-send-email or as an attachment)? Apologies, I pasted that from an Org buffer without reformatting. Attac

Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: Attaching a proper patch with your suggested revisions here. Sorry, I'm not used to submitting patches through email. I see it inlined on my end, but it does not appear as if it was attached. Trying once more: >From 289d3ff93c9f7f56ee54d98fd7d6294c4472a37b Mon S

[RFC] DOCT: Declarative Org Capture Templates

* [RFC] DOCT: Declarative Org Capture Templates I've been working on an alternative syntax for org-capture-templates. The result is a package called "DOCT" (declarative org capture templates): https://github.com/progfolio/doct A brief list of what I believe to be improvements over the curren

Re: [RFC] DOCT: Declarative Org Capture Templates

Nicolas Goaziou writes: Hello, No Wayman writes: * [RFC] DOCT: Declarative Org Capture Templates Thank you for your work. Thank you for taking the time to respond. Disclaimer: I am only using very basic capture templates. So, I cannot comment realistically on the new syntax you

[PATCH] Allow org-capture-mode-hook to access org-capture-current-plist [9.3.6 (release_9.3.6-443-g0e8aff @ /home/n/.emacs.d/straight/build/org/)]

I'm proposing the following trivial patch to bring more consistency to org-capture-mode's hooks. By setting org-capture-current-plist before invoking org-capture-mode in the capture buffer, users can access the same variable in org-capture-mode-hook as they would in org-capture-before-finalize

Re: [Patch] Document org-capture-templates entry type default strings

Any interest in this patch?

Re: [Patch] Document org-capture-templates entry type default strings

No Wayman writes: Any interest in this patch? Apologies, intended this to be a reply to: https://lists.gnu.org/archive/html/emacs-orgmode/2020-03/msg00317.html

Re: [Patch] Document org-capture-templates entry type default strings

Kyle Meyer writes: IIRC, when I reviewed another series, you were nearing a number of changes at which we should make sure you've assigned copyright to the FSF. Assuming you haven't already, please consider doing so (see ). T

[Bug]: org-capture-place-plain-text error when template :unnarrowed

org-capture-place-plain-text throws an error for templates which meet the following criteria: - entry type is 'plain - the template has a non-nil :unnarrowed option - the template string is not empty and does not explicitly include "%?" Seems to be thrown in this section of org-capture

Re: [Bug]: org-capture-place-plain-text error when template :unnarrowed

Note, the empty string or a nil template do not cause the error.

Re: [Patch] Document org-capture-templates entry type default strings

Bastien writes: People at the FSF may be having difficulties with processing these requests due to the current situation. If you don't get an answer within a week, I'll send an email to see what delays we can reasonably expect. Thanks, Bastien. You're probably right re current situation

Re: [Patch] Document org-capture-templates entry type default strings

Bastien writes: Hi, No Wayman writes: I assume I'll receive some sort of confirmation from FSF when everything is processed? Yes, you should receive a confirmation - if not within a week or so, let me know, sometimes asking again helps. Best, Received confirmation. I will s

Re: [PATCH] Allow org-capture-mode-hook to access org-capture-current-plist [9.3.6 (release_9.3.6-443-g0e8aff @ /home/n/.emacs.d/straight/build/org/)]

Nicolas Goaziou writes: Could you add the modified function in the commit message, add TINYCHANGE cookie if you haven't signed FSF papers yet, and add an entry in ORG-NEWS about it? I've modified the commit message and added an ORG-NEWS entry in the attached patch. My FSF papers have rece

[PATCH] etc/ORG-NEWS: fix broken documentation link

Saw this error after `org-lint'ing ORG-NEWS while I was adding an entry for another patch. The attached patch fixes a broken link for `org-clock-in-last'. >From f5b6859031d2bf487b26475d84420363b5b29f02 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Mon, 8 Jun 2020 14:59:44 -0400 Subjec

[PATCH] capture: respect KEYS with GOTO arg [9.3.7 (release_9.3.7-661-g4aa4dd @ /home/n/.emacs.d/straight/build/org/)]

`org-capture' does not pass its KEYS argument to `org-capture-goto-target'. (Must not be a common use-case, as git blame points to org-capture's introduction 10 years ago!) The attached patch does just that. Wasn't sure if this was worthy of a NEWS entry. Will add if needed. Thanks, Nichol

Re: [PATCH] capture: respect KEYS with GOTO arg [9.3.7 (release_9.3.7-661-g4aa4dd @ /home/n/.emacs.d/straight/build/org/)]

Kyle Meyer writes: After applying, I added "lisp/" in front of the file name and capitalized "pass". Pushed (99b8f36ab). Thanks, Kyle. Noted for future patches.

Re: time-warping - retroactively marking DONE?

I emailed Adam directly with an experimental package I wrote to solve the problem of changing the todo-state of an entry at an arbitrary time. He suggested I posted here as well: https://github.com/progfolio/epoch/ The package advises current-time to return `epoch-current-time' if is set (

Re: [PATCH] org-capture: Update plist before finalizing (Leo Vivier)

I needed a similar workaround in doct: https://github.com/progfolio/doct/blob/80d291e5f1cbdabd4eb7f88c917653c59d3f14be/doct.el#L589-L592 I restore `org-capture-plist' to the value of `org-capture-current-plist' after the `org-capture-before-finalize-hook' is run. As of: https://code.orgmo

Re: [Patch] Document org-capture-templates entry type default strings

Nicolas Goaziou writes: Could you send it again with a commit message more in line with our habits (variable modified, etc), and two spaces at the end of sentences? Sorry for the delay. I've reformatted the patch. >From cf52a18e4f2ca3c5138975c790fb6baec08d5c87 Mon Sep 17 00:00:00 2001 From

Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-pc-l

If `org-toggle-item' is called between the text of an entry and the next heading, it removes the tags from the next heading. ECM: With the following Org markup in a buffer and point denoted by "|": #+begin_example ,* First Some text | ,** Second :tag: #+end_example invoking `org-toggle

Re: Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-

I've attached a patch which removes the call to skip-blanks if there is no active region. This works for me with the ECM I've provided. Not sure if it will have any adverse repercussions outside of that. >From ada4f2a55b7a701aac02d4fc167be4b46e72f2c9 Mon Sep 17 00:00:00 2001 From: Nicholas V

Re: Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-

Kyle Meyer writes: Would you mind updating the patch to add a test case along the lines of your ECM to test-org-list/toggle-item? Thanks. Added the test in the attached patch. Thanks, Kyle. ~ Nicholas Vollmer >From 838a6a548396eecfa958161abb66f0a1719a9aef Mon Sep 17 00:00:00 2001 From:

[PATCH] org-get-cursor-date regexp patch

The regular expression in `org-get-cursor-date' assumes the time grid string will have two digits in the hour portion of the time strng. However, the grid time string does not always have two digits. For example: " 8:00.." The attached patch accounts for this and uses the rx macro to c

Re: [PATCH] org-get-cursor-date regexp patch

Makes sense. IMO it'd be nice to see something along the lines of this explanation in the commit message itself. The function name is missing here: * lisp/org.el (org-get-cursor-date): ... To my eyes, the new variable doesn't add any clarity over keeping it inline. Addressed in att

Bug: eldoc error: (void-function nil) [9.3.7 (release_9.3.7-708-g5417e3 @ /home/n/.emacs.d/straight/build/org/)]

The patch to org-eldoc applied in b2b587387 still throws an error: eldoc error: (void-function nil) I was unable to step through this because (I think) eldoc causes the debugger to close as soon as input is received. The error occurs when `eldoc--invoke-strategy` attempts to funcall eldoc-do

Re: Bug: eldoc error: (void-function nil) [9.3.7 (release_9.3.7-708-g5417e3 @ /home/n/.emacs.d/straight/build/org/)]

Kyle Meyer writes: Assuming it's fine with you, I'll squash this into your patch. Fine by me

Bug: Org bold emphasis gobbles leading stars on next headline [9.3.7 (release_9.3.7-710-g3f04ad @ /home/n/.emacs.d/straight/build/org/)]

ECM: With the following Org mode file and point denoted by "|": * Parent | ** Sibling Insert the text "*", resulting in: * Parent "*"| ** Sibling textually, but the final star of the Sibling heading is hidden as well: * Parent "*"| Sibling I believe the org-hide face is being overridd

[PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

The current behavior of `org-add-planning-info' does not include the time of day when it is passed the TIME argument. This is because `org-time-was-given' is initially let-bound to nil during the scope of the function. The attached patch removes that binding and allows the caller to pass the

[PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

I like seeing a month long habit consistency graph, but this usually overwrites most of the information on each agenda habit line unless the window is particularly wide. The attached patch adds a customizable option to place the graph. I'm using it now to place each habit's graph on a new line

Re: [PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: I'm using it now to place each habit's graph on a new line below the habit at `org-habit-graph-column'. Forgot to mention, this also has the added benefit of not displacing the tags on each habit's line.

Re: [PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: It makes this sort of customization very simple Famous last words. I forgot the agenda relies on text-properties for much of its functionality. I've attached a patch that addresses this and also removes the `save-excursion` around the funcall to the custom inse

Re: [PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

Ihor Radchenko writes: As I remember, last time I played with multi-line agenda entries, there were issues with org-agenda-next/previous-item. You may consider checking if your patch breaks those. Thanks for the heads up, Ihor. The patch itself shouldn't break anything and is completely opt

Re: time-warping - retroactively marking DONE?

Adam Spiers writes: Many thanks again for this. It's working great for me! In case anyone's interested, here's my use-package config (which uses the awesome straight.el package manager to install it): https://github.com/aspiers/emacs/blob/aa62bd84b51a02cb0fc980862a63514349d253bf/.emacs.d

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: Applied in maint as c7abcd514, thanks. Thanks, Bastien. I noticed org-end-time-was-given is bound similarly. This binding doesn't affect my usage, but I wonder if it is necessary. If you think it isn't, I'd be happy to submit another patch removing it.

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: If you can investigate why the test broke, that'd be helpful. Thanks! Unfortunately I'm unable to get the test suite to run correctly. I've followed the instructions in the testing/README, but the tests hang due to some sort misconfiguration with python and readline on my

Re: idea for capture anywhere in x

I use a deamon specifically for this. Here's a gist with my setup (thought slightly out of date, this will work as a base): https://gist.github.com/progfolio/af627354f87542879de3ddc30a31adc1

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

Jack Kamm writes: Also, could you try executing some simple ob-python session blocks and see if they hang? e.g., #+begin_src python :session :results output print(1+1) #+end_src #+begin_src python :session :results value 1+1 #+end_src These both work for me now on master as of f17d30

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: Hi No Wayman, I pushed 4f49ebb6d, a small variant of your initial patch, which pass the test fine by checking whether the variables are bound outside or not, ignoring them if not. Thanks again for the fix! Sounds good to me! Thanks, Bastien.

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

Kyle Meyer writes: As I mentioned in the message linked upstream, it doesn't happen when running just test-org/org-read-date (BTEST_RE='test-org/org-read-date'), so there's some sort of interaction between tests. Sorry, I was a little late getting to this, and it seems to be resolved- bu

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: No Wayman writes: Well, back to square one -- the "fix" breaks setting the end time of an existing schedule timestamp for me with. I reverted it as 771c66f79. Unfortunate, but I see the same breakage with the patch. I stepped through trying to set and end

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

I'll keep researching and see if I can come up with anything. This is particularly difficult. When instrumenting `org-add-planning-info` with edebug the resulting timestamp always has its time portion (given and/or end-time) ignored. Tried it with both my personal setup and emacs -q. No lu

Bug: org-capture: %L causes arg out of range error for empty string annotation [9.4 (release_9.4-31-g8c44f2 @ /home/n/.emacs.d/straight/build/org/)]

d06aa486d6c3163b6ef6e9ab665117bd93dff34a introduces the following in `org-capture-fill-template': (v-L (if (or v-a (string-match l-re v-a)) (replace-match "\\1" nil nil v-a) v-a)) If `v-a' is an empty string, the call to `replace-match' throws an Args out of

Re: Bug: org-capture: %L causes arg out of range error for empty string annotation [9.4 (release_9.4-31-g8c44f2 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: If `v-a' is an empty string, the call to `replace-match' throws an Args out of range error. Similar assignments in that area of the code use an `and' comparison to guard against this, so perhaps it should be: (v-L (if (and v-a (string

Re: org-capture at point

Since org-plus-contrib 20200920, I'm no longer able to get org-capture to insert a template at the point. Instead, it seems to place the entry at the appropriate heading level, above the current heading. Looking at the help page, perhaps it's this behavior: This happens with both a custom inte

Re: org-capture at point

Looks like it was introduced with: f5573e6a0 org-capture.el: Fix heading's level when inserting a template "here" I believe the issue is due to `org-back-to-heading' moving point when calculating the heading level. The attached patch corrects the issue on my end. Tested by running: #+begin

Re: Proposal: do not align tags in Agenda

I recently proposed a patch that would allow a workaround for this: https://orgmode.org/list/87ft8gelpn@gmail.com/ It allows custom placement of the habit consistency graph within the agenda. There is an accompanying example that places the graph on its own line under the agenda item. I've at

Bug: [PATCH] org-agenda: "Invalid face reference: t" errors [9.4 (release_9.4-49-g4b150d @ /home/n/.emacs.d/straight/build/org/)]

I noticed recently that my message buffer was getting clobbered with thousands of Invalid face reference errors when moving point around an org-agenda buffer. e.g.: Invalid face reference: t [4519 times] Git bisect points to commit 7a12e149907b5921011710d869b7554c35859c89 org.el (org-d

[BUG] [PATCH] Ensure org-babel-temporary-stable-directory bound-and-true [9.6 (9.6-g713598 @ /home/n/.emacs.d/elpaca/builds/org/)]

Updated today and noticed an error when killing Emacs. See attached. >From fa822d45559267de6af31f9d34be4266af602d03 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Tue, 5 Jul 2022 19:03:44 -0400 Subject: [PATCH] lisp/ob-core.el: fix file-exists-p error * ob-core.el (org-babel-remove-temp

Re: [BUG] [PATCH] Ensure org-babel-temporary-stable-directory bound-and-true [9.6 (9.6-g713598 @ /home/n/.emacs.d/elpaca/builds/org/)]

Sorry, that symbol should not be quoted in the patch. Amended attached. >From 87c400fa8cb3ffa9b4fcf1f958feab4506194a81 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Tue, 5 Jul 2022 19:03:44 -0400 Subject: [PATCH] lisp/ob-core.el: fix file-exists-p error * ob-core.el (org-babel-remove

[PATCH] ob-core.el: Fix docstring single quotes [9.6 (9.6-gc66bdb @ /home/n/.emacs.d/elpaca/builds/org/)]

Emacs 29's byte compiler warns about single quotes in docstring examples. Emacs : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-06-28 Package: Org mode version 9.6 (9.6-gc66bdb @ /home/n/.emacs.d/elpaca/builds/org/) >From 6bf0e44615

[PATCH] DOCT integration: template specific hooks [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

The attached patch is the first step toward integrating DOCT[1] syntax into Org mode. It adds property options to org-capture-templates which make it easier to run template-specific hooks. The current approach for running such hooks involves adding to the desired global hook variable and filteri

Re: [PATCH] DOCT integration: template specific hooks [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

No Wayman writes: The attached patch is the first step toward integrating DOCT[1] syntax into Org mode. It adds property options to org-capture-templates which make it easier to run template-specific hooks. The current approach for running such hooks involves adding to the desired global

Re: [PATCH] DOCT integration: template specific hooks [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

Attached is a revision which fixes a typo in a comment. >From af1d14439d6ada284b5f9b8f17a3da2a172808f1 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Tue, 27 Sep 2022 05:44:33 -0400 Subject: [PATCH] org-capture: Add template hook properties * lisp/org-capture.el (org-capture-templates):

Re: [PATCH] DOCT integration: template specific hooks [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

On second thought, I'd prefer the keywords to allow a single function or a list of functions. This prevents breakage with current DOCT syntax and is cleaner IMO. e.g. #+begin_srce emacs-lisp :lexical t (let ((org-capture-templates '(("t" "test" plain (file "/tmp/test.org") "test %?"

[BUG] [PATCH] Template elements: fix doc typo [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

Attached patch adds closing mark up for code in definition list. >From d2ac397ea9dc4265f38cab070dccbbb82c61148f Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Tue, 27 Sep 2022 20:27:07 -0400 Subject: [PATCH] doc/org-manual.org fix capture Template elements typo --- doc/org-manual.org |

[BUG] org-element: defsubst org-element--cache-active-p used before defined [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

Byte compiling in a clean environment yields the following warning: org-element.el:11:5682 Warning: defsubst ‘org-element--cache-active-p’ was used before it was defined. I'll leave a patch to whoever is maintaining this feature because it will involve hoisting several other variables to

Re: [PATCH] DOCT integration: template specific hooks [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

I've addressed your comments in the attached patch. I based it off the most recent patch in the thread. The main difference is that the hook properties accept a single nullary function or list of nullary functions. >From 90f0c68e1149512b51230fd44ad728b38e5f088e Mon Sep 17 00:00:00 2001 From:

[PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

In order to properly generate org-version.el, the current build in mk/targets.mk requires a query of the repo's tags. Shallow clones do not have tags and so org-version will be generated as "N/A". In the attached patch, support for generating org-version.el from shallow clones is added. It is

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

No Wayman writes: Sorry, wrong commit value in the previous patch. Fixed the patch attached here. >From a4cd70e17455894aec5d15d97eb41b56769e5cde Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Sun, 15 Jan 2023 15:44:45 -0500 Subject: [PATCH] * mk/targets.mk (GITVERSION): supp

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

Ihor Radchenko writes: What we should not have is "make autoloads" failing without internet. The attached patch should take care of that. If the ls-remote errors, GITVERSION will be set to N/A as when it is generally unavailable. >From 4ce8b2dfc2cf2ca1507aa14be15f5212eb1de229 Mon Sep 17 0

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

Ihor Radchenko writes: No Wayman writes: Ihor Radchenko writes: What we should not have is "make autoloads" failing without internet. The attached patch should take care of that. If the ls-remote errors, GITVERSION will be set to N/A as when it is generally unavailable.

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

No Wayman writes: The attached patch should take care of that. Sorry. Had trailing whitespace in that version. Attached here without trailing whitespace. >From 85990610ca7572f5a6ff7604d957efdf00747094 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Mon, 16 Jan 2023 14:00:41 -0

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

Ihor Radchenko writes: No Wayman writes: No Wayman writes: The attached patch should take care of that. Thanks! I played a bit more with the patch and noticed that remote tag lookup is not performed prior to _any_ make command. For example, there is a noticeable delay on my

Re: [PATCH] Support building Org from shallow clone [9.6.1 (release_9.6.1-137-gecb62e @ /home/n/.emacs.d/elpaca/builds/org/)]

Ihor Radchenko writes: No Wayman writes: Feel free to take this the patch as a base to do whatever you please with it. Then, I am thinking about a simple approach that will not involve internet connection. See the attached. I think that's the best solution. I landed on some

Re: [PATCH] Introduce "export features"

often we include content in export templates that is only relevant in particular situations. “export features” allow for the specification of qualities of the org buffer being exported that imply certain “features”, and how those features may be implemented in a particular export. now `\

Re: [POLL] Naming of "export features"

⁃ Providing capabilities via snippets can be framed as akin to dynamically gaining a feature. I understand some snippets may be used to, for example, include a latex package. However, it's not a requirement that a snippet "add a feature/capability" to a document. What that snippet does d

Re: [POLL] Naming of "export features"

And to add: https://books.google.com/ngrams/graph?content=adaption%2Cadaptation%2Ccontext%2Cenhancement%2Cenrichment%2Cfeature&year_start=1800&year_end=2019&corpus=en-2019&smoothing=3 It appears context is king. All that aside, I think Ihor's proposal sidesteps the whole issue while addressin

Re: [POLL] Naming of "export features"

Ihor Radchenko writes: I am looking at the concept again, and I feel that we may be missing some flexibility here. I do not like the fact that each feature can only have a simple implementation within specific backend. Agreed What I have in mind is an ability to parametrize the transco

Re: [POLL] Naming of "export features"

Timothy writes: I hadn’t thought of applying the term “enrichment”. That or adaptation could be a good fit. I think I like the sound of “enriching the export”, and I could probably also be sold on “export adaptation” / “adaptive export”. Both are horribly abstract in my opinion. If the ai

Re: Can a post-capture hook know which capture template I used?

https://www.github.com/progfolio/doct may be helpful here

Re: [PATCH] org-capture.el: Allow `(here)' as a template

`org-capture-store-last-position' will signal an error if a template with a target of (here) is invoked from a buffer which is not backed by a file.

Re: [PATCH] org-capture.el: Allow `(here)' as a template

No Wayman writes: Evaluating the following source blocking an org mode buffer with no backing file: Interesting. I'm only able to reproduce it some of the time. I'll look into it more when I have time, but it may have been an artifact of my Emacs session. I was able to trigge

  1   2   >