Ihor Radchenko writes:
> It has been a while.
> Rudolf, may I know if you are still interested in this patch?
I am currently super-duper busy with uni assignments. If you can whip
it out in a couple of minutes, please do. Basically, we want the
`graphviz-dot-mode' to be enabled when editing Gr
I've tracked the issue down, but not sure about
the best way to fix it. I've attached a patch but
worry that it might have unintended side effects.
This only affects :file when it is set on a src block.
If :file is provided via properties there is no problem.
The call stack is
org-ctrl-c-ctrl-c
[ Readding tomás since this thread got more high-level again ... ]
On 2025-04-20 13:27, Ihor Radchenko wrote:
> Looks reasonable.
Thanks. More or less by chance I let Org's ERT tests run with
`org-timestamp-formats' set to `("%Y-%m-%d" . "%Y-%m-%d %H:%M")'.
(I do not intend to do anything like
Hello Orgers
I am not sure if it is a bug, but when I call
(org-publish-find-title "/absolute/path/to/org/file.org" '(""))
I get an error "Wrong type argument: hash-table-p, nil", I assume from
the snippet
(gethash (cons filename property) org-publish-transient-cache)
in the funtion org-pu
Here's the output of git bisect.
38be85124551083d26981ab3c22d7b09632b7b10 is the first bad commit
commit 38be85124551083d26981ab3c22d7b09632b7b10
Author: Nicolas Goaziou
Date: Fri Dec 22 00:06:39 2017 +0100
ob-core: Do not always evaluate Lisp code in parameters
* lisp/ob-core.el (org
Ihor Radchenko writes:
> Ihor Radchenko writes:
>
>>> Fallback to `org-sort-function'.
>>
>> I am not sure if it is the best idea to hard-code using
>> `org-sort-function' here.
>>
>> What if a user wants specific `org-sort-function' for, say, table
>> sorting, but something else for tags?
>> Se
"Bob Newell" writes:
>> That's a terrible terrible idea to pollute agenda view with tasks that
>> do not absolutely need to be done on a given day. Such agenda is useless
>> in the long run.
>
> A terrific insight. While I think I mostly use orgmode effectively this is a
> mistake I'm clearly m
Hi,
I have found a bug where using #+call: on a block will fail to
execute :file elisp, saving to the string rather than the evaluated
result. It is on main at 9f3ee0fa5e3e8835dd34f134f05840aa28a21f5f.
It is present in org 9.4.4 that comes with Emacs 27.2, but it is NOT
present in org 9.1.9 that
Better use testing/lisp/text-ox-md.el header that does not have such
line.
Adapted it accordingly.
Regarding the prefix-topic: I was a bit confused with that and thought
that this must be some sort of "special test convention" that I am not
aware of. Sorry for that, and thanks for clarifying.
On Sun, Apr 20, 2025, at 08:20, Ihor Radchenko wrote:
> That's a terrible terrible idea to pollute agenda view with tasks that
> do not absolutely need to be done on a given day. Such agenda is useless
> in the long run.
A terrific insight. While I think I mostly use orgmode effectively this
Corwin Brust writes:
> On Mon, Jan 20, 2025 at 4:27 PM Bastien Guerry wrote:
>>
>> Also thinking about Worg again: I don't know what Corwin and Krupal
>> think, but maybe Worg deserves more maintainers?
>
> More maintainers sounds great!
Should I create a call for maintainers?
And, btw, what sh
Ihor Radchenko writes:
> https://orgmode.org/worg/worg-about.html says "Their role is to take
> care of the Worg repository and to empower new maintainers and
> contributors.", but I am not sure what "take care" refers to here.
Well, that's a good question.
"Taking care of Worg" means making th
Thank you very much.
Ihor Radchenko writes:
> Sébastien Gendre writes:
>
>> I have attached, to this e-mail, the corrected patch that include your
>> requests.
>
> Thanks!
> Applied, onto main, with minor amendments to the manual text.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/com
Günter Lichtenberg writes:
> I also have a lot of projects that are shifting and changing and regularly
> something
> unscheduled pops up. Maybe a bit obvious, but what helped me most was to set
> aside time
> every week on Friday (as org habit "Plan Next Week") to (re)organise tasks
> for
On Sunday, 20 April 2025 19:50:43 CEST Ihor Radchenko wrote:
> Bastien Guerry writes:
> > I've finally found some time to describe my Org workflow:
> > https://bzg.fr/en/the-zen-of-task-management-with-org/
> > ...
> > And I'm curious to see how it compares to other workflows.
>
> Do you ever nee
Ihor Radchenko writes:
> In my setup, TODO implies "here is a task, I should likely be done, but
> I still need to figure out the details".
Yes... as Rudolf suggested, I will try "PLAN" for this.
--
Bastien
Rudolf Adamkovič writes:
> Idea: Perhaps the default TODO keyword could mean "next" and the
> "inventory" tasks could use a new keyword, like IDLE, PLAN, or L8TR.
Good idea! I switched to using ONGO/TODO/PLAN as you suggest, and I
updated the blog post. Thanks!
--
Bastien
Hi,
About a half year ago I had a data corruption that crippled into my
email and todo lists (including backups). As a result, a number of
emails were lost.
I have managed to recover most of the public emails from the mailing
lists and some, but likely not all the private emails.
As of today, I
Rudolf Adamkovič writes:
> Idea: Perhaps the default TODO keyword could mean "next" and the
> "inventory" tasks could use a new keyword, like IDLE, PLAN, or L8TR.
> That way, one does not hide items from the agenda by mistake.
Depends. TODO is kind of the default.
In my setup, TODO implies "here
Bastien Guerry writes:
> I guess you draw a similar line between ONGO and other keywords, with
> "ONGO" having a similar meaning to "activated" for me.
Good point! Both next and ongoing parameterize the task along the same
axis. I will stop using priorities, then. Thank you for taking the
tim
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> I just found https://ikiwiki.info/plugins/contrib/org_mode/ implementing
>> exactly this idea for ikiwiki engine.
>
> Great! Also, ikiwiki seems stable and the maintainer is still active, so
> he might be interested to know that you're conside
> Ihor Radchenko writes:
> I did it myself, adding proper commit messages, news entries, and
> :package-version keywords. Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=62a5910d87https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9f3ee0fa5e
Pedro Andres Aranda Gutierrez writes:
> Would you be more comfortable with fallbacks for the individual families in
> the font-mappings-alist?
> I could try to go for something like:
>
> (defvar org-latex-font-fallback-alist
> '(("main . '(("emoji" . "Noto Color Emoji:mode-harf")
>
David Masterson writes:
>>> The issue is level -- is it (1) the number of stars in the header or do
>>> the stars mean (2) 1=highest and N=lowest level. Since this is a
>>> "programmer's editor", my tendency is toward #1 (level=star#) and avoid
>>> the use of inferior/superior in favor of above/b
HI,
After a lot of consideration, more testing and some reading (including
pandoc, thanks again for the inspirational source) I feel that this is the
best approach for a first generation of the patch. It would provide relief
for many situations and a starting point for further improvement.
This fu
tani...@ss.iij4u.or.jp writes:
> When the variable `org-highlight-latex-and-related' is set to `(latex)',
> opening an Org file and inserting or deleting characters may cause too
> much time lag, making text editing difficult.
Thanks for reporting and for providing the detailed analysis!
This is
"Dwarshuis, Nathan J" writes:
> revised/rebased patch attached which no longer skips standard props
Thanks!
> * lisp/org-element.el (org-element--interpret-affiliated-keywords):
> Optimize performance by bypassing unnecessary types and reducing
> loop complexity. Added new constant
> `org-eleme
Pedro Andres Aranda Gutierrez writes:
> The font configuration is done in two variables:
>
> (defvar org-latex-font-mapping-alist
> '(("main" . "Noto Serif")
> ("sans" . "Noto Sans")
> ("mono" . "Noto Sans Mono"))
> "Set this alist for your font preferences when exporting to
> LuaLaTe
Ihor Radchenko writes:
> May you please split the patch into multiple - one per feature, document
> the new features in etc/ORG-NEWS, and add a proper commit message to the
> patches?
I did it myself, adding proper commit messages, news entries, and
:package-version keywords.
Applied, onto main.
>
> I am reviewing this complex bug report now.
> Looks like everything should be fixed.
> Fixed.
> Let me know if you still see problems.
>
I will do, thanks. I've not seen the problem for months.
On Sun, Apr 20, 2025 at 11:41 AM Timothy wrote:
> On Wed, Mar 12, 2025, at 1:51 AM, Ihor Radchenko wrote:
> > Nikolaos Chatzikonstantinou writes:
> >
> >> Shouldn't the source blocks be using the element?
> >>
> >> This patch is untested, I can pay more attention to it if first the
> >> maintain
Alexander Adolf writes:
> Ihor Radchenko writes:
>
>> [...]
>> I am finally back to this request.
>> Please see my take on changes to the manual.
>> [...]
>
> This looks great, and IMO is a big improvement adding the desired
> clarity.
Applied, onto main, after cleaning up unintended changed th
32 matches
Mail list logo
