On 29 July 2020 09:29, Gustavo Barros wrote:
> But what will happen is that the task will be both "done" and "due" on
> the same day. Which face shall org-habit use? Which symbol?
> And that `org-habit-duration-to-days' performs its conversion of the
> repeaters to days with `floor', I'd say
On 29 July 2020 08:15, Gustavo Barros wrote:
> Furthermore, considering the only thing org-habit does is to provide
> the consistency graph for the task, and if this does not really work
> for hourly repeaters, I still don't see the gain here. And there
> would be other ways, in my view more
> Is there any way to do this or are the docs out of date?
I made a few quick changes to org-habit and it works prima facie. Will
continue testing for a bit.
>From e690d7b43143410d5d5af524bb1ff0819feebc24 Mon Sep 17 00:00:00 2001
From: nivekuil
Date: Mon, 27 Jul 2020 04:37:32 -0700
Subject:
According to the manual at
https://orgmode.org/manual/Repeated-tasks.html hourly repeating tasks
are possible, but the code in org-habit.el seems to disagree, explicitly
disallowing an interval <1d:
(error "Habit %s scheduled repeat period is less than 1d" habit-entry))
Is there any way
On 3 June 2020 15:26, Nicolas Goaziou wrote:
> You only need the last `org-id-goto' call right? Is the call to this
> function meaningful, or can point be left at the beginning of "A1"
> headline instead?
Yes, I should have mentioned that you need to start in overview view.
The idea is to
On 31 May 2020 04:09, Nicolas Goaziou wrote:
> I just fixed it, IIUC. Thank you.
It works indeed. However, I believe I have found another bug :)
Try these commands with the following org file; it appears to fail to land on a
heading:
(org-id-goto "105dfe8b-8507-400c-862f-a25882448051")
On 3 June 2020 09:27, Kevin Liu wrote:
> (org-next-previous-heading)
Typo; this should be (org-previous-visible-heading)
> There is a good reason for this. If you insert text at (point-max), you
> break the following headline.
>
> OTOH `org-mark-element' should pay attention to buffer boundaries.
Good point. `org-mark-element` uses (org-element-property); I wonder if
it makes sense to have the actual :end
On 30 May 2020 09:09, Nicolas Goaziou wrote:
> You cannot call `org-cycle' consecutively without care, because it
> checks `last-command' and `this-command'. You need to fake their values
> before calling `org-cycle' again.
Good to know, thanks.
Relatedly, would you be willing to take a look
I’m trying to add a test (which should fail at the moment, representing
an org-mode bug), but it seems like each ‘should’ form is actually
nondeterministic. The first form returns nil on the first eval and t on
subsequent evals, its behavior resetting upon any command, and the
second form does
Oh, of course I attached the wrong patch again. Wish mu4e-compose could
preview these.
>From 5f7cf68f92d3fa82d01646f7f1e12a4d18bad2fb Mon Sep 17 00:00:00 2001
From: nivekuil
Date: Sat, 30 May 2020 00:11:19 -0700
Subject: [PATCH] Make narrowed subtree same size as the subtree, not 1 char
less
I noticed that when I narrow to a subtree and then hit org-mark-element,
I can’t kill the text because the narrow is actually 1 char smaller.
This seemed like an unpleasant workaround, and I think the behavior can
be changed without any real negative consequences.
>From
nless (org-at-heading-p) (outline-next-heading))
(org-capture-mark-kill-region origin (point))
- (org-capture-narrow beg (point))
+ (org-capture-narrow beg (if (eobp) (point) (1- (point
(org-capture--position-cursor beg (point))
(defun org-capture-place-item ()
--
2.26.2
On 29
This is a patch to fix my previous report of a regression in capture
behavior between 9.3 and 9.3.6:
> Basically, the last position in the narrowed org-capture is actually
> the first position on the next line, so when you go to (end-of-buffer)
> and start typing you start clobbering the next
Thanks, it does indeed seem to be fixed on master.
On 27 May 2020 18:23, Kyle Meyer wrote:
> Kevin Liu writes:
>
>> Basically, the last position in the narrowed org-capture is actually
>> the first position on the next line, so when you go to (end-of-buffer)
>> an
This old thread describes similar behavior:
https://emacs.stackexchange.com/questions/37097/newlines-swallowed-by-org-capture
Basically, the last position in the narrowed org-capture is actually the first
position on the next line, so when you go to (end-of-buffer) and start typing
you start
This bit in org-agenda-finalize:
(save-excursion
(while (org-activate-links (point-max))
(add-text-properties (match-beginning 0) (match-end 0)
'(face org-link
Will throw an error at add-text-properties:
Debugger entered--Lisp error:
17 matches
Mail list logo
