A recent commit on Emacs master branch changes the return value of
pp:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d3311499339fab0371cb7502a1e2481fbcd2c65d
The function does not document a stable return value, either.
This causes babel emacs-lisp source blocks to return "nil" for t
(elpaca-test
:interactive t
:init
(elpaca org
(setq org-hierarchical-todo-statistics nil)
(with-current-buffer (get-buffer-create "*org-bug*")
(insert "* TODO test [/]\n")
(insert "** TODO Loop Infinitely")
(goto-char (point-min))
(re-search-forward "/" nil t)
(
Ihor Radchenko writes:
point on trailing blank line: FAIL
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6d7c7917a
Confirmed on my end by adding `:packages* org` to the previous
test:
Yodel[1] Report 2023-11-27 15:34:45
===
[Apologies for the duplicate message, Ihor. mu4e recently changed it's default
reply behavior without my noticing]
Ihor Radchenko writes:
> This is very different from LAX argument in `org-at-timestamp-p' -
> timestamp-like text may not be proper syntactically correct Org markup
> element, but
When on an empty line before a source block, org-in-src-block-p
correctly returns nil.
However, when on an empty line after a source block, it returns t.
This is reproducible on my end with both the built-in version of
Org and 9.7-pre.
Yodel[1] Report 2023-11-27 10:42:54
==
When compiling Org, I get the following warning:
In org--get-expected-indentation:
org.el:19192:8: Warning: Useless clause following default ‘cond’
clause
I looked at the source and confirmed it is not a false positive.
The following code is unreachable due to the (t ...) cond clause
before
Ihor Radchenko writes:
Thanks!
You're welcome.
It looks like ob-lilypond/ly-compile-lilyfile test is relying on
this
optional second argument. So, after applying your patch, make
test is
failing.
I've amended the test using cl-letf.
I also bound the variables which may generate output
See attached.
>From 9b21849b9b7d9f36f57241e80d005535f07b788c Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer
Date: Sun, 3 Sep 2023 15:41:51 -0400
Subject: [PATCH] ob-lilypond.el: Fix docstring typos
---
lisp/ob-lilypond.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/li
Ihor Radchenko writes:
- Removes the optional TEST parameter, which is unused and
better
served through debugging tools.
This is technically a breaking change. So, we (1) need to
mention it in
ORG-NEWS; (2) may consider (file-name &optional _) function
definition
to be 100% sure that
The attached patch:
- Improves the compilation message. (The target is the file, not
LilyPond itself).
- Refactors the body of the function to remove the many
nondescript arg-n local variables.
- Removes the optional TEST parameter, which is unused and better
served through debugging tools
Ihor Radchenko writes:
No Wayman writes:
The attached patch satisfies all but two checkdoc warnings.
I left those two for someone more familiar with the package.
Thanks!
Subject: [PATCH] * lisp/ob-lilypond.el: satisfy checkdoc
_S_atisfy.
(org-babel-lilypond-compile-post-tangle
The attached patch satisfies all but two checkdoc warnings.
I left those two for someone more familiar with the package.
>From ecd5fe22458db64d86650a1a7a1e697d9ccff020 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer
Date: Thu, 24 Aug 2023 08:20:22 -0400
Subject: [PATCH] * lisp/ob-lilypond.el: s
From: Ihor Radchenko
I am not sure if I like this approach.
I have 2 problems with the patch:
1. Previous users of :lexical header arg might be surprised.
Though it is an OK breaking change since people who used
:lexical
argument and expected it to be ignored in the tangled file
Ihor Radchenko writes:
No Wayman writes:
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
arti
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
`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.
https://www.github.com/progfolio/doct may be helpful here
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
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
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
⁃ 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
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 `\
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
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
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
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.
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
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
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
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:
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
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 |
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 %?"
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):
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
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
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
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
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
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
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
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
-
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
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
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
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
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
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
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 +---
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
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
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
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
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
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 ch
The attached patch addresses most of the checkdoc warnings for
org-capture.
There are two remaining warnings (both the same):
Disambiguate org-capture-mode by preceding w/
function,command,variable,option or symbol.
I did not address these because checkdoc has recently been fixed
to stop a
Bastien writes:
Hi,
No Wayman writes:
Instead of a defvar that we don't want the user to modify, why
not
hardcoding the addition of the coma? I'd prefer this.
`completing-read-multiple' is currently used in two spots to read
tags:
`org-set-tags-command' a
Bastien writes:
Hi,
No Wayman writes:
* org.el (org-tags-crm-separators): Defcustom controlling which
characters are used to delimit tags in commands which utilize
`completing-read-multiple'.
Why should we allow anything else than ":" for separating tags
in
command
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 (d
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 already
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,
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
F
Kyle Meyer writes:
On 09/23/21 17:17:48 -0400, No Wayman wrote:
It looks like you've unintentionally added a ')' to the end of
the
GITVERSION line.
Apologies. Must've been a stray.
Another approach would be to update org.el's version to contain
something that
Sounds like a weird issue. I don't think this 9.5-dev tag is
something from the Org repo.
There is a bug in mk/targets.mk introduced by 61336f80dc.
As others have pointed out, the new repository does not have tags.
As a fallback, org.el's version is read in it's header.
However, it looks like K
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:
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.
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
expli
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
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
Curren
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
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
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
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
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 inco
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'?
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 g
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.
--
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
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.
Thanks for doing the bisect.
I was in the process of doing it myself and comparing disassembled
byte-code when I saw the patch had been pushed.
For anyone curious, this particular bug was a byte compilation
error.
When byte-compiled, org-capture-fill-template was attempting to
compare strings
from an earlier thread, I recall you mentioned you were using
native
compilation? This is almost certainly the cause of your problem.
This does smell like a byte-compilation problem.
Seems to be a failure with any interactive, single-character
%-escaped patterns in a template string (e.g. %
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:
https://github.com/raxod50
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 thawing.
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 you'r
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 t
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 s
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 permission
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 org-bab
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 care
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.
--
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 =org-cap
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 o
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 emacs-lisp
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 (&optional arg)
"comple
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.
-
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
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
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
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
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
1 - 100 of 155 matches
Mail list logo
