Thanks for the bump. Life stuff popped up and I got distracted by other
hacking too.
On Thu, Jun 19 2025, Ihor Radchenko wrote:
> Ihor Radchenko writes:
>
>>> Thank you for the clarification. WDYT of the patches attached?
>>
>> See my comments below.
>> ...
>
On Mon, Jun 09 2025, Ihor Radchenko wrote:
> Kristoffer Balintona writes:
>
>> So, to be clear, you find that having an org project/todo heading for
>> each email thread suffices, since (i) all todos in the same thread end
>> up under the same project which makes (ii
On Mon, Jun 09 2025, Christian Moe wrote:
> Kristoffer Balintona writes:
>
>> (N.B. Christian Moe elsewhere in this thread something that gave me
>> inspiration. As a notmuch user, I think it wouldn’t be too hard to add a
>> visual indicator on individual emails for whet
On Sun, Jun 08 2025, Ihor Radchenko wrote:
> Kristoffer Balintona writes:
>
>> My main problem with trying to use org-agenda for all tasks created from
>> emails is that the state and relevance of those emails may change
>> without the todos tied to them changing (unless
lar to non-sexp org-ql)
Is there a necessity for org-element’s cache to be sparse? Is it mostly
to avoid having to parse entire buffers (or at least large chunks of
them) when they change? When I first heard about org’s caching, I had
the (extremely) naive question of what technical reasons there are to
not just store entire parse trees in a cache, even an on-disk one.
--
Kind regards,
Kristoffer
his,
I’ll file a bug report. But if no one experiences this, then there’s a
good chance the cause is something to due with my configuration.
--
Kind regards,
Kristoffer
.
Am I missing something?
--
Kind regards,
Kristoffer
part).
Martin can chime in and share to correct me if I’m wrong.
--
Kind regards,
Kristoffer
On Sat, May 24 2025, hob...@poukram.net wrote:
> Kristoffer Balintona writes:
>
>> [... 19 lines elided]
>>>
>>> I've been using mu4e for a while now, but in my gnus email days I
>>> used gnorb, and I dearly miss those features in my current
>>&
On Wed, May 21 2025, Christian Moe wrote:
> Kristoffer Balintona writes:
>
>> My main problem with trying to use org-agenda for all tasks created from
>> emails is that the state and relevance of those emails may change
>> without the todos tied to them changing (unless
On Wed, May 21 2025, Rémi Letot wrote:
> Christian Moe writes:
>
>> Kristoffer Balintona writes:
>>
>> [... 8 lines elided]
>>
>> I don't have any cure-all workflow for this, but I can think of a
>> feature that would help facilitate it: e-mail
x27;s interesting that you keep emails "grouped" by year to
help... I hadn't thought of that before. I'll consider it. Although I'd
personally use time span shorter than a year...
--
In gratitude,
Kristoffer
my difficulties sufficiently. I
thought I'd ask the org community in case anyone has found a workflow
they're happy with.
--
In gratitude,
Kristoffer
Hi Ihor,
I apologize for the delay. I've been busy these last few days and also
encountered some technical difficulties with my device.
On Sun, May 11 2025, Ihor Radchenko wrote:
> Kristoffer Balintona writes:
>
>>> Why not just using nil value as you initially suggested?
&
On Sun, May 11 2025, Ihor Radchenko wrote:
> Kristoffer Balintona writes:
>
>> Thank you for the help. I've attached a diff for a set of proposed
>> changes. It has `org-capture-expand-olp' and
>> `org-capture-expand-headline' return the symbol 'file
Whoops, I forgot to include in my diff the small test I added. I've
attached the full diff here.
--
Best,
Kristoffer
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 6d395406cf..f418e9fba9 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -205,24 +2
On Thu, May 08 2025, Ihor Radchenko wrote:
> Kristoffer Balintona writes:
>
>> Currently, `org-find-olp' assumes that it is being passed a file path +
>> an outline path, but when the olp function returns nil, only a file path
>> is returned, so `org-find-olp'
On Mon, May 05 2025, Ihor Radchenko wrote:
> Kristoffer Balintona writes:
>
>> On Mon, May 05 2025, Kristoffer Balintona wrote:
>
>> It would be nice if the top-level datetree in would simply
>> be used if the function supplied for function-returning-lis
On Mon, May 05 2025, Kristoffer Balintona wrote:
> It would be nice if the top-level datetree in would simply
> be used if the function supplied for function-returning-list-of-strings
> returns nil.
Seems like the attached diff can accomplish this, though I'm not sure if
it'
-location, I'm not sure how easy
this would be easy.
--
Best,
Kristoffer
nk you for the patch! I was going to do it myself, but you beat me to
it.
I now see that there is a small mention in the docstring that the file
need not be a path but also variable or function, but "/path/to/file"
convinced me otherwise.
--
In gratitude,
Kristoffer
portion in org-capture-set-target-location that lets me choose which
file I'd like to capture to.
--
Best,
Kristoffer
items, and so on--but
that's the gist of it.
Footnotes:
[1] Or, with delay cookies, certain items in the future.
[2] For me, this is just TODO and NEXT.
[3] https://github.com/brabalan/org-review
--
Best,
Kristoffer
n't think. Have you made
customizations to display-buffer-alist?
>
>
> Best regards
>
> ---
> Gendre Sébastien
>
>
--
Best,
Kristoffer
be done to fix this, but I'm not
sure if I'm supposed to categorize this as a [BUG] so I've marked the
subject as a [FR] instead.
Regards,
Kristoffer
f late here, but I hope I came across somewhat coherently.
Regards,
Kristoffer
26 matches
Mail list logo
