[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/)]

s." Thanks for your time, no wayman Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1) of 2018-09-24 Package: Org mode version 9.1.14 (9.1.14-1-g4931fc-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20180917/) current state: == (setq org-duration-form

[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

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

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 see that this is an alias

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'

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.

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

lt 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: > > (defalias 'org-highest-priority 'org-priority-highest) > > be > > (defvaralias ..

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 Sep 17

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.

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

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

[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

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

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

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

[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

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

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

[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

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

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):

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/)]

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

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 an

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

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

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-

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

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

[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

[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

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/)]

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

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 insertion

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

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

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-match l-re v

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:

[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

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:

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

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

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

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

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

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.

[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,

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

[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

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

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 submit

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:

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

Re: Bug: org.el has wrong (or none) version [fatal: No names found, cannot describe anything. (fatal: No names found, cannot describe anything. @ /Users/niels/.emacs.d/straight/build/org-agenda/)]

I don't know anything about straight, but this sounds like what you'd get if you try to generate org-version.el in an Org repo without tags. This is the correct assessment. Straight has a user option, `straight-vc-git-default-clone-depth', which may be customized to perform shallow clones

Re: Org Capture Menu cannot be fully viewed

Pietru: If you are extensively using Org's capture templates I suggest taking a look at: https://github.com/progfolio/doct A brief summary of some of the benefits it provides: - Allows capture template inheritance - Checks for certain errors in template declarations *before* capture. -

Re: Org Capture Menu cannot be fully viewed

What is here missing is `org-capture-by-completing-read' so that user may select among many various capture templates. Compensating for initial bad design is expensive effort. Are you suggesting something like this?: #+begin_src emacs-lisp (defun +org-capture-read ( arg) "completing

[feature] capture: defcustom for item/checkitem to skip LOGBOOK [9.4.4 (release_9.4.4-159-g9140a7 @ /home/n/.emacs.d/straight/build/org/)]

Consider the following file named "/tmp/capture-item-logbook.org": start capture-item-logbook.org --- * TODO TASK SCHEDULED: <2020-12-30 Wed 21:30 ++1d> :PROPERTIES: :STYLE:habit :END: :LOGBOOK: - State "DONE" from "TODO" [2020-12-29 Tue 21:30] :END: :+begin_src

Re: new org-contrib and straight.el

Hi, Greg. The recent changes to org-contrib's location/structure have been accounted for on straight's "develop" branch. Once on that branch you can rely on the default recipe: #+begin_src emacs-lisp (straight-use-package 'org-contrib) #+end_src You can see which version of straight

Re: new org-contrib and straight.el

Greg Minshall writes: Nick, ...i have not been getting the updated org-mode info pages with my org package. Straight provides its own means of building/installing package info. This may be a bug with the Org mode recipe we provide. Please file a bug report at:

Re: new org-contrib and straight.el

Greg Minshall writes: Nick, The recent changes to org-contrib's location/structure have been accounted for on straight's "develop" branch. Once on that branch you can rely on the default recipe: thanks very much. i'll look at switching to the development branch, freezing and

Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /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.

Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

Kyle Meyer writes: Bastien writes: Hi, thanks for the patch, we do indeed need to move forward for this. Could you propose the patch against the master branch (not the maint branch, since this is not a bugfix) and perhaps fix *all* warnings? Thanks, but these were already taken

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

Sébastien Miquel writes: Hi, No Wayman writes: I'm tangling my early-init/init.el with the :tangle-mode header arg set to (identity (#o444)). This should be `(identity #o444)` I believe ? Apologies, I transcribed that incorrectly. I do have `(identity #o444)`. File permissions

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

Sébastien Miquel writes: Hi Bastien, Bastien writes: I tried to apply this (transitory?) patch against maint and it did not apply. It applies okay on master. For bug fixes, please make patches againt the maint branch. This fixes a bug introduced by a commit in master. I've attached the

Re: Bug: [PATCH] org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

Sébastien Miquel writes: Here's another patch, to be applied on top of the previous one, that fixes this. The specific case you mention can also be achieved by setting the :tangle argument to `yes`: in this case, the tangled file name is computed using the buffer file name and changing

Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

I'm tangling my early-init/init.el with the :tangle-mode header arg set to (identity (#o444)). The idea behind this was to prevent myself from accidentally editing the tangled source files instead of the Org files. Unfortunately, since a3cb9b853 there seems to be a behavior change for

Re: org-capture: question about function to create template

From: Joost Kremers To: emacs-orgmode@gnu.org Subject: org-capture: question about function to create template Message-ID: <87eeggh0r5@fastmail.fm> Content-Type: text/plain Hi list, I've been looking at the =org-capture= mechanism a bit more closely recently and noticed that in

Re: [PATCH] Rename headline to heading

As far as org-capture is concerned, support for transparently upgrading the user's templates could easily be added to the `org-capture-upgrade-templates` function. It would just be one more case added to the existing pcase statement and would prevent breakage for users.

Re: [PATCH] Rename headline to heading

No Wayman writes: As far as org-capture is concerned, support for transparently upgrading the user's templates could easily be added to the `org-capture-upgrade-templates` function. It would just be one more case added to the existing pcase statement and would prevent breakage for users

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: See the attached patch for a first draft implementation. Attached is a second draft which compiles cleanly and makes use of mapconcat where appropriate. >From 079f116f6bedcf2c2b1d08c18d71d8e432d94d38 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Fri, 3 Sep 2

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Allen Li writes: Sorry about that (I wrote the crm patch). I did not consider people deliberately using invalid tag characters to separate tags. It's an (un?)happy coincidence that org-set-tags-commands retains this behavior, because the fast tags selection logic gets in the way. The

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Timothy writes: Ah, right — that looks sensible. I think we should probably note that in a comment somewhere, Yes, a comment is warranted. I'll address minor issues like this once a solution is agreed upon. or perhaps construct the regexp with `rx' so it’s actually using `org-tag-re'?

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Timothy writes: Reading your thoughts I’m inclined to agree, perhaps it’s best if we settle on a set of “sensible” separation characters, document them, and leave it at that. NoWayman, what do you think of that? I disagree with the idea that it shouldn't be customizable. See the second

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: No Wayman writes: See the attached patch for a first draft implementation. Attached is a second draft which compiles cleanly and makes use of mapconcat where appropriate. [2. org-tags-crm-separators-2 --- text/x-patch; 0001-Add-org-tags-crm-separators.patch

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Timothy writes: Hi NoWayman, Thanks for your suggestion. At a glance it looks reasonable to me, but would you be able to explain the default value you’ve set? It isn’t obvious to me how you arrived at `"[ \t]*[^[:alnum:]_@#%][ \t]*"'. Also, do you think a one-size-fits-all solution is a

Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

Timothy writes: Hi NoWayman, I ran into this with some code I’m writing which checks against `lexical-binding’. Should the following result in “lexical binding enabled” or “lexical binding disabled”?: Can you think of any examples where this results in different behaviour (without

Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: The third case I outlined. Tangling a :lexical t src block sults in a dynamically scoped file unless the user manually inserts the file-local variable line. *results That's adjacent to the issue I originally raised, but we could do better in that case.

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Allen Li writes: green-blue is recoverable, and green:blue is not. Consider a file where some headings are tagged :green:blue: and some are tagged :green_blue:. If green-blue gets changed into :green:blue:, then it is no longer possible to tell which :green:blue: headings are supposed to

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

Tim, Allen: The attached compromise implements the bare minimum. Tags can be separated with "," or ":" in the previously mentioned cases. Scrapped the defcustom and showing delimiters in the prompt. Any objections? >From 31fbfca4884083adacd95054155cda9ed0128fba Mon Sep 17 00:00:00 2001 From:

[BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

I ran into this with some code I'm writing which checks against `lexical-binding'. Should the following result in "lexical binding enabled" or "lexical binding disabled"?: #+begin_src emacs-lisp :lexical t (message "lexical binding %sabled" (if lexical-binding "en" "dis")) #+end_src

Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

My thoughts on this would be that if lexical-bindings is supposed to be bound to t, it should be done by eval when it gets a non-nil value for it's optional argument. If I execute (eval FORM t) in an emacs lisp buffer, it looks like lexical-bind is not set either, so I don't think it should

Re: [PATCH] Declare functions for byte compiler [9.5 (9.5-g769a55 @ /home/n/.emacs.d/straight/build/org/)]

No Wayman writes: And one more in org-attach.el. See attached. >From 21620549a24703697d65c46bc88258cd4b2aaa80 Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Sat, 25 Sep 2021 15:05:08 -0400 Subject: [PATCH] Fix byte-comp function warnings * (org.el, org-attach.el, org-keys.el,

[PATCH] Declare functions for byte compiler [9.5 (9.5-g769a55 @ /home/n/.emacs.d/straight/build/org/)]

Recent changes have introduced byte-comp warnings for unknown functions at compile time. These warnings are "louder" now that more users are native compiling Elisp, so one more reason to avoid them. See attached patch. >From 736e72b56b10ba451016e4cc07305d8065c02ac9 Mon Sep 17 00:00:00 2001

Re: [PATCH] Declare functions for byte compiler [9.5 (9.5-g769a55 @ /home/n/.emacs.d/straight/build/org/)]

Bastien writes: That's not just org-attach.el, right? The patch does not apply either in the bugfix or in the main branch. Could you resend it, also wrapping the body of the ChangeLog at <80 lines? M-x change-log-mode RET can help. TIA! Sorry. Didn't realize the first patch had

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] 502/slow response from new repo [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

Experiencing 502 errors and delay when trying to clone the new development repo: time git clone https://git.savannah.gnu.org/git/emacs/org-mode.git Cloning into 'org-mode'... remote: Counting objects: 129920, done. remote: Compressing objects: 100% (28292/28292), done. remote: Total 129920

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

See attached. >From 7fbdca5dc81dfe0dd542ed0e2352d3334b16fd7f Mon Sep 17 00:00:00 2001 From: Nicholas Vollmer Date: Mon, 27 Sep 2021 20:35:12 -0400 Subject: [PATCH] org-id: Fix checkdoc warnings * org-id: Fix checkdoc warnings. --- lisp/org-id.el | 31 +-- 1 file

[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

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

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.

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

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:

[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

  1   2   >