Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[TEC]

Bastien  writes:

You register once and for all?  Is there some red tape involved 
in

maintaining the registration?


Assuming I haven't misread/missed anything, the only thing that we 
might
cause a change is if the specification changes - but since it 
looks like
we can just link to our specification we probably wouldn't even 
need to

do that.


For that, I think a formal syntax specification would be
needed. Perhaps https://orgmode.org/worg/dev/org-syntax.html 
will

do? It looks complete.


We should first read 
https://orgmode.org/worg/dev/org-syntax.html
and carefully check that it is up to date and still accurate, 
then
make it more user oriented (for now it more developers 
oriented.)


I see. Would there be someone well suited to check that everything 
is

accurate? I wouldn't feel confident auditing the whole document by
myself.


I'm ready to work on this before the end of the year.


Marvellous!

Perhaps it could be worth putting the syntax spec under the 
main

site as something like orgmode.org/syntax-spec.html.


I would not go into this direction: as you know, I'd like the 
home
of orgmode.org to be just one page (index.org/html) and move 
other

pages to Worg.  So let's not move org-syntax.org to the website,
it is good as a worg resource.


Mmm. My thoughts on having lots on Worg haven't changed, I was 
just
thinking it might seem more 'official' / better if the page were 
nearer

to the site root.

I've also been considering spinning off the manual into a bit 
of a
specification document (e.g. less of a guide / how-to, stripped 
down

to just the bare information), so perhaps
orgmode.org/specification.html#syntax ? I'd really like some 
second

opinions.


This would be too many docs to maintain.


This was partly motivated from it sometimes being annoying to just
check what forms an element can take and not finding it easy to 
see in

the manual.

Yea, maintaining /another/ file doesn't seem like a good idea 
though...



Is anyone willing to move forward with this registration?


In about two months, I am.


Okay, thanks!  Let's work on stabilizing Org syntax and 
reconsider the
registration idea then.  I will also ping future maintainers on 
this.


Sounds good! Thanks for being open to the idea :)

All the best,

Timothy.

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Hi Timothy,

TEC  writes:

>> Is anyone willing to check that there are no constraints?
>
> I've read through https://tools.ietf.org/html/rfc6838 and I couldn't
> see any constraints placed on us beyond the initial registration's
> requirements.

You register once and for all?  Is there some red tape involved in
maintaining the registration?

> For that, I think a formal syntax specification would be
> needed. Perhaps https://orgmode.org/worg/dev/org-syntax.html will
> do? It looks complete.

We should first read https://orgmode.org/worg/dev/org-syntax.html
and carefully check that it is up to date and still accurate, then
make it more user oriented (for now it more developers oriented.)

I'm ready to work on this before the end of the year.

> Perhaps it could be worth putting the syntax spec under the main
> site as something like orgmode.org/syntax-spec.html.

I would not go into this direction: as you know, I'd like the home 
of orgmode.org to be just one page (index.org/html) and move other
pages to Worg.  So let's not move org-syntax.org to the website,
it is good as a worg resource.

> I've also been considering spinning off the manual into a bit of a
> specification document (e.g. less of a guide / how-to, stripped down
> to just the bare information), so perhaps
> orgmode.org/specification.html#syntax ? I'd really like some second
> opinions.

This would be too many docs to maintain.

>> Is anyone willing to move forward with this registration?
>
> In about two months, I am.

Okay, thanks!  Let's work on stabilizing Org syntax and reconsider the
registration idea then.  I will also ping future maintainers on this.

Thanks,

-- 
 Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[TEC]

Bastien  writes:


If there is absolutely zero burden put on the shoulders of Org's
maintainers, then I'm all for it.


From the look of things, there's just effort in the initial 

creation.


I think it would serve well the proliferation and
popularization of org-mode.


Agreed.


This is the main reason why I'm a fan of the idea :)


Is anyone willing to check that there are no constraints?


I've read through https://tools.ietf.org/html/rfc6838 and I 
couldn't see
any constraints placed on us beyond the initial registration's 
requirements.


For that, I think a formal syntax specification would be needed. 
Perhaps
https://orgmode.org/worg/dev/org-syntax.html will do? It looks 
complete.


I'm hoping we could then use https://tools.ietf.org/html/rfc7763
(registration of text/markdown) as a template, where we could just 
link

to the syntax specification.

Perhaps it could be worth putting the syntax spec under the main 
site as

something like orgmode.org/syntax-spec.html.

I've also been considering spinning off the manual into a bit of a
specification document (e.g. less of a guide / how-to, stripped 
down to

just the bare information), so perhaps
orgmode.org/specification.html#syntax ? I'd really like some 
second

opinions.


Is anyone willing to move forward with this registration?


In about two months, I am.

It looks like creating and draft and then emailing it to
media-ty...@iana.org would probably be the best approach.

All the best,

Timothy.

Re: Customize resheduling behaviour

[Ihor Radchenko]

> Is there a way to reshedule it, if it fails 1 week later and if I
> complete it, reshedule 2 weeks later?

There is no built-in way to do it, but you can always write your own
org-trigger-hook.

Alternatively, you can also use org-edna. Something like

:TRIGGER: if self todo-state?("FAILED") then self scheduled!("++14d") 
todo!("TODO") else self scheduled!("++7d") todo!("TODO") endif

Best,
Ihor

Stefan Huchler  writes:

> I have a task sheduled like that:
>
> * TODO  Order from a delivery service
>   SCHEDULED: <2020-10-06 Di .+2w>
>
> So if I understand the resheduling correctly if I miss the task, it
> get's resheduled 2 weeks later (probably deadline would be better here)?
>
> But the delivery service delievers weekly I just choose to only order
> all 2 weeks from it. So if I miss a date I would shop myself for 1
> week and then order again 1 week later not 2 but if I succeed I only
> order 2 weeks later.
>
> Is there a way to reshedule it, if it fails 1 week later and if I
> complete it, reshedule 2 weeks later?

Re: Customize resheduling behaviour

[David Masterson]

Stefan Huchler  writes:

> I have a task sheduled like that:
>
> * TODO  Order from a delivery service
>   SCHEDULED: <2020-10-06 Di .+2w>
>
> So if I understand the resheduling correctly if I miss the task, it
> get's resheduled 2 weeks later (probably deadline would be better here)?
>
> But the delivery service delievers weekly I just choose to only order
> all 2 weeks from it. So if I miss a date I would shop myself for 1
> week and then order again 1 week later not 2 but if I succeed I only
> order 2 weeks later.
>
> Is there a way to reshedule it, if it fails 1 week later and if I
> complete it, reshedule 2 weeks later?

You could probably set something up with the org-edna package on MELPA.

-- 
David Masterson

[ANN] Second (and final) Call for Proposals for EmacsConf 2020 (closing Oct 7)

[Amin Bandali]

Fellow denizens of the Emacs-verse,

This is the second and final Call for Proposals for EmacsConf 2020,
which was extended through October 7 (next Wednesday).  Please see below
for details on how to submit your proposal(s), and how to chat about or
get help with your proposals via our #emacsconf IRC channel on freenode.

If you'd like to give a talk but you're not entirely sure what about, a
few folks have helpfully added some ideas on this year's Ideas page at
, and previous Ideas pages contain
many interesting ideas as well.  Myself and the other folks hanging out
at #emacsconf would also be happy to chat with you about potential ideas
for your talk.

We look forward to your proposals!

 * * *

  ___

 EmacsConf 2020
   Online Conference
  ___


November 28 and 29, 2020


Table of Contents
_

1. Important dates
2. Talk formats
3. Topic ideas
4. Submission
5. Getting involved


Update 2020-09-14: Added timezone information (9am to 5pm Toronto/EST).
Moved CFP end date to October 7, 2020.

The [Call for Proposals] for [EmacsConf 2020] is now open, until
*October 7, 2020*.

After a successful EmacsConf 2019, we are back again this year and are
once again calling for your participation!

EmacsConf is the conference about the joy of [Emacs], Emacs Lisp, and
memorizing key sequences.

We are holding EmacsConf 2020 as a virtual (online) conference again
this year, especially now, given the current state of the world with the
ongoing global pandemic.  We remain fully committed to freedom, and we
will continue using our infrastructure and streaming setup consisting
entirely of [free software], much like the last EmacsConf.

We welcome speakers of *all backgrounds* and *all levels of experience*,
including newcomers submitting a proposal to give their first talk!


[Call for Proposals] 

[EmacsConf 2020] 

[Emacs] 

[free software] 


1 Important dates
=

  Mark your calendars: EmacsConf 2020 will take place on November 28-29!
  We're planning for 9am to 5pm Toronto/EST (2pm-10pm UTC, 3pm-11pm
  Zurich/CET).  Depending on people's availability, it might be two
  half-days.

   CFP opens  August 24, 2020
   CFP closes October 7, 2020 (new date) 
   Speaker notifications  October 14, 2020   
   Schedule published November 7, 2020   
   EmacsConf 2020!November 28 and 29, 2020   

  Please note that although we will try our best to stick to the above
  dates in the coming months, given the current state of the world, we
  may have to move things around a bit in case of unforeseen events.
  Thank you for bearing with us as we all navigate these trying times.


2 Talk formats
==

  The following are the main formats for EmacsConf 2020 talks:

  - *10 minutes* (Lightning talk): Quickly present a cool project,
concept, or trick in 10 minutes or less!

  - *20 minutes* (Standard talk): Introduce the audience to a new Emacs
mode, concept, or just talk about something not necessarily shiny
and new but that you find really neat nonetheless.

  - *50 minutes* (Extended talk): Take your time going more in depth,
and/or do a demo!  Extended talks are a great way of really
educating the audience about something you enjoy.

  We hope to have lots of great submissions this year, just like last
  year.  In order that as many people as possible can present, it helps
  if presenters can be flexible about their time slots.  So, for
  non-lightning talk submissions, please let us know besides your main
  preferred format if a shorter format would also work for your talk.

  Q time is *included* in the Standard and Extended time slots; please
  time your presentation accordingly.  If you would like to take
  questions live, we recommend aiming for a 15-minute presentation for
  the Standard time slot, and for 40-45 minutes for the Extended time
  slot.  However, as the speaker, the exact allocation of your time is
  up to you, so long as it does not exceed the allocated time slot.

  Other session formats such as tutorials, workshops, and hangouts are
  welcome as well, especially considering all that is going on around
  the world, in case you would find those other formats preferable to a
  traditional talk format.  If you are interested in these or other
  session types, please get in touch with us publicly or privately; we
  will be happy to work something out with you.

  To help minimize disruptions in case of potential technical issues
  that may arise during the conference, we ask that our speakers either
  schedule a short 

Re: Links in complete org-todo-keyword-face not highlighted

[Kyle Meyer]

Bob Wilson writes:

> I often put links in TODOs, but it would appear that in org 9.4,
> marking a task complete changes the font of the entire text (link and
> non-link) to be the same color, so the link is no longer highlighted.
[...]
> I tried searching the mailing list to see if this has been discussed
> previously but didn’t see anything. Any help would be appreciated!

In v9.4, the default of org-fontify-done-headline changed to t, which
results in the org-headline-done face applied.  You can set it to nil to
restore the previous behavior.

Links in complete org-todo-keyword-face not highlighted

[Bob Wilson]

Hi folks,
   I often put links in TODOs, but it would appear that in org 9.4, marking a 
task complete changes the font of the entire text (link and non-link) to be the 
same color, so the link is no longer highlighted.

Minimal org file:
```
* TODO This is a [[https://www.gnu.org][test] ]
```

When I open this in emacs, it looks like:
```
* TODO This is a test
```
with “test" being highlighted blue and underlined. When I mark it complete, it 
looks like:
```
* DONE This is a test
```
with “test” being brown, the same as the rest of the test. Notably, if I 
position point over test and hit “C-c C-o” the link still opens, so the link is 
definitely still there, it just looks the same as the rest of the header. That 
leads me to believe it is an incompatibility between the org-link face and 
org-todo-keyword-face, but I’m not 100% sure.

- Using emacs 26.3 on my personal laptop and 27.1 on my work laptop (problem 
occurs in both versions).
- Using Mac OSX Catalina everywhere.
- Using org version 9.4. I’m not 100% sure, but the problem doesn’t seem to 
have been present in 9.3.6, which is what I was using before upgrading to 9.4. 
I’ve been using 9.4 on my work laptop for a week or so, but was using 9.3.6 on 
my personal laptop. When I noticed the problem on my work laptop, I checked if 
it was also present on my personal laptop, but the behavior was as expected 
(link remains highlighted, font did not change colors at all actually when 
marking as complete). When I upgraded my personal laptop to 9.4, the problem 
appeared there too.
- No init.el (or .emacs) file. For some reason the problem does *not* occur 
when I run `emacs -nw -q`, but it does occur when I run `emacs -nw` after 
renaming my init.el file. I thought -q was equivalent to ignoring the init.el 
file, but I guess not!

I tried searching the mailing list to see if this has been discussed previously 
but didn’t see anything. Any help would be appreciated!

Kind regards,
Bob Wilson

Re: opening a 0.5 MB org file is slow

[Jeremie Juste]

Re: opening a 0.5 MB org file is slow

[Jeremie Juste]

Hello Uwe,

Very well, it seems that we are on the right track. So you might gain
some speed by preventing some minor modes to load at the beginning and
load only when you need them.

Like Ihor Radchenko mentioned in his previous a great way to diagnose
the issu would be the following:

1. M-x profiler-start cpu
2. open your file
3. M-x profiler-report 

It will let you see which functions are slowing you down.

HTH,
-- 
Jeremie Juste

Re: Customize resheduling behaviour

[Richard Lawrence]

Hi Stefan,

Stefan Huchler  writes:

> I have a task sheduled like that:
>
> * TODO  Order from a delivery service
>   SCHEDULED: <2020-10-06 Di .+2w>
>
> ...
> Is there a way to reshedule it, if it fails 1 week later and if I
> complete it, reshedule 2 weeks later?

I don't think there's any way to do this automatically when you change
the TODO state of the entry.

The simplest way I can think of is to do C-c C-s +7 (i.e., call
org-schedule and give a new date a week later at the prompt). If doing
this on a different day than the scheduled day, you'll need to change
the interval you enter (e.g., if you missed it by 2 days, enter +5) or
type in the new date manually.

Another option is C-c C-x c (i.e., org-clone-subtree-with-time-shift).
Clone the tree one time, with a shift of one week, then delete the old
tree. The advantage of this option is that the time shift will be
relative to the old scheduled/deadline date, not the date on which you
run the command, so you can always say +1w.

Hope that helps!

-- 
Best,
Richard

Re: opening a 0.5 MB org file is slow

[Uwe Brauer]

>>> "T" == TEC   writes:

> Samuel Wales  writes:

>> a long time ago i discovered that drawers were the bottleneck. i
>> removed a lot of them and got much faster loading speeds.  idk if
>> that
>> is still true.

> There's a thread about improving this, see:
> https://orgmode.org/list/87h7x9e5jo.fsf@localhost/

Thanks I tried it out. Did not really help :-(


smime.p7s
Description: S/MIME cryptographic signature

Re: opening a 0.5 MB org file is slow

[Uwe Brauer]

>>> "JJ" == Jeremie Juste  writes:

Hi Jeremie


> Hello Uwe,
> Can you test with emacs -Q ?


I did and then it is much much faster, so the question is which of my
dozens of org files slow it down.


smime.p7s
Description: S/MIME cryptographic signature

Re: Framing images?

[Eric S Fraga]

On Wednesday, 30 Sep 2020 at 11:21, Mike Gauland wrote:
> I'd like to have a frame around images in my exported documents. I'm
> primarily interested in LaTeX export, but html is a secondary concern.

There are definitely LaTeX ways of doing this (e.g. using mdframed is
the best I've found for general framing of both text and images
[1]).  But obviously these won't work for HTML export.

You might, however, be able to get what you want with a 1 row 1 column
table?

eric

Footnotes:
[1]  https://www.ctan.org/pkg/mdframed

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-38-g16f505

Re: opening a 0.5 MB org file is slow

[Eric S Fraga]

On Tuesday, 29 Sep 2020 at 23:06, Jeremie Juste wrote:
> A 1.6M org file took a little under 7 sec on my computer.

A 2.1MB file took about 11 seconds on my computer (not new but high spec 8 
years ago: multiple Xeon processors with a lot of memory but probably slow 
disk).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-38-g16f505

Re: PATCH: Display point of code block point when confirming evaluation

[Eric S Fraga]

On Wednesday, 30 Sep 2020 at 12:57, TEC wrote:
> +1 for line numbers

Likewise.

And, just to be greedy, the name of the source block as well would be
very useful (if present).  I do tend to name all of my blocks, if only
to help with navigation by being able to jump to any block from anywhere
else in the file/buffer.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-38-g16f505

Re: Website revamp?

[Maxim Nikulin]

01.09.2020 23:39, TEC wrote:

Maxim Nikulin  writes:


Installation page

I am uncertain if it is applicable for other editors, but I would
like to see name of vim plugin since ambiguity (or matter of taste)
exists.. FAQ suggests other vim plugins. I do not remember if I saw
vim-outliner somewhere on orgmode.org. I have not tried any of
these plugins.


Each entry is a link to the extension/plugin in question, is this not 
sufficient?


I think that in respect to vim it is more complicated, so

"Vim: see 
[[https://orgmode.org/worg/org-faq.html#org-outlines-in-vim][FAQ]];


may be more appropriate. However FAQ entry should be updated. Certainly 
jceb/vim-ormode should be added. On the other hand I do not consider 
vim-orgmode as the absolute winner. VimOrganizer is not actively 
maintained but it supports table alignment. Unfortunately internal links 
require a fix. Recent https://github.com/axvr/org.vim , 
https://www.reddit.com/r/orgmode/comments/fbewla/orgvim_a_very_minimal_org_mode_and_outline_mode/ 
is very simple in comparison to projects mentioned above, but header 
folding and syntax highlighting work well. In FAQ it should be mentioned 
in addition to older http://www.vim.org/scripts/script.php?script_id=1266 .


I suppose, the choice depends on features the user is looking for. E.g. 
if neither agenda nor even syntax compatibility with org mode is 
required, any folding syntax rules with Utl.vim (universal text links) 
could be a viable alternative for a note-taking application with some 
spirit of org. It seems, it is difference of expectation that causes 
proliferation of plugins and bring lists like 
https://vim.fandom.com/wiki/Script:List_of_scripts_for_outlining


That is why I found the link that just looks as "vim" rather obscure and 
confusing. Even "vim: vim-orgmode plugin" item is better since a name of 
particular plugin is visible without additional actions as following the 
link or hovering it with mouse (if it is available). Explicitly 
presented name allows to recall it later.


If you decide to update FAQ (maybe it is better to discuss it in a 
dedicated thread), please, do not wipe "obsolete" links completely. Some 
phrase "previously we recommended ..." could add a value for those who 
read the old variant and is trying to figure out where they saw such 
suggestion.

Customize resheduling behaviour

[Stefan Huchler]

I have a task sheduled like that:

* TODO  Order from a delivery service
  SCHEDULED: <2020-10-06 Di .+2w>

So if I understand the resheduling correctly if I miss the task, it
get's resheduled 2 weeks later (probably deadline would be better here)?

But the delivery service delievers weekly I just choose to only order
all 2 weeks from it. So if I miss a date I would shop myself for 1
week and then order again 1 week later not 2 but if I succeed I only
order 2 weeks later.

Is there a way to reshedule it, if it fails 1 week later and if I
complete it, reshedule 2 weeks later?

Re: Timestamps: overnight repeater possible?

[Stefan Huchler]

I think that is what I also had inn mind, but I care more about the
resheduling part, wouldn't that work with sheduling it on day x and then
have a deadline day x+1?

thu...@arcor.de (Thomas Plass) writes:

> Hi subscribers,
>
> can multiday timestamp ranges be made repeatable?  Case in point: I'd
> like to create the timestamp(s) for an "after-hour" time span ranging
> from 18:00 in the evening til the following morning 10:00, repeated
> every day.
>
> I tried these:
>
> * Overnighter (listed for 2000-01-03 and -04 only)
>   <2000-01-03 Mo 18:00>--<2000-01-04 Di 10:00>
>
> * Overnighter (has cookie, but doesn't repeat beyond -04)
>   <2000-01-03 Mo 18:00 +1d>--<2000-01-04 Di 10:00 +1d>
>
> * 6 o'clock Repeater (repeats, but is overnight only notionally)
>   <2000-01-03 Mo 18:00-10:00 +1d>
>
> Agenda week view looks like this (when opening the last timestamp):
>
> Week-agenda (W01):
> Montag  3 Januar 2000 W01
>   manual: 18:00.. (1/2):  Overnighter (listed for 2000-01-03 and -04 
> only)
>   manual: 18:00.. (1/2):  Overnighter (has cookie, but doesn't repeat 
> beyond -04)
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
> Dienstag4 Januar 2000
>   manual: 10:00.. (2/2):  Overnighter (listed for 2000-01-03 and -04 
> only)
>   manual: 10:00.. (2/2):  Overnighter (has cookie, but doesn't repeat 
> beyond -04)
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
> Mittwoch5 Januar 2000
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
> Donnerstag  6 Januar 2000
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
> Freitag 7 Januar 2000
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
> Samstag 8 Januar 2000
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
> Sonntag 9 Januar 2000
>   manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only 
> notionally)
>
> I'd like the "Overnighter" to be listed for every day.
>
> Thanks for any suggestions!
>
> Thomas

org-num-mode for RTL languages

[Daniel Fleischer]

Hi, 

Org-num-mode doesn't work for RTL language (e.g. Hebrew) when 
`bidi-paragraph-direction` is set to `left-to-right`.  
It does work when one sets `bidi-paragraph-direction` to nil. 

Example text:


* Test

* עברית

* עוד אחד

* Back to English



I would expect it to work either way because sometimes the file reads better 
when everything is aligned left-to-right. 

Thanks, 
Daniel

Re: org-babel support for haxe

[ian martins]

I wrote the ob-core patch I mentioned before but white writing the commit
message I realized there's probably no need to modify ob-core at all. I was
doing it in order to allow haxe and java to create subdirectories in the
babel temp directory since both languages require class names to match file
names and directory structures to match the class' package (which is like
namespace in C). But for executing babel code blocks from the temp
directory all that is needed is the output; the source file doesn't matter.
I'll try updating the haxe and java patches to build and run directly from
the babel temp directory.

On Thu, Sep 24, 2020 at 5:17 PM ian martins  wrote:

> with ob-java I assumed I shouldn't change ob-core, so I advised/overrode
> ob-core instead of changing it. But it would be much better to change
> ob-core. I'll submit those changes as a separate patch that modifies
> ob-core.
>
> On Sun, Sep 13, 2020 at 4:04 PM Kyle Meyer  wrote:
>
>> ian martins writes:
>>
>> > ob-haxe and ob-java both involve a few changes to ob-core to allow temp
>> > directories instead of just temp files. Should I submit that as a
>> separate
>> > patch?
>>
>> It looks like that change is included with your ob-java patch [0], which
>> will be considered after 9.4 is released [1], so I think it's fine as
>> is.  (In my opinion, splitting up that patch would have been nice, but I
>> don't think it's worth a reroll, at least until some initial comments
>> come in.)
>>
>> [0]
>> https://orgmode.org/list/CAC=rjb7ahmnrq9nc4ao07qk3qzf4lvatmu_r1fwqr+97npn...@mail.gmail.com
>> [1] https://orgmode.org/list/87sgbwgvx6@gnu.org
>>
>

Bug: org-clock-select-task reuses reserved characters [9.3 (release_9.3 @ /home/unhammer/PREFIX/emacs/share/emacs/28.0.50/lisp/org/)]

[Kevin Brubeck Unhammer]

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.


If your org-clock-history has 44 or more elements, then the "c"
character will no longer go to the current task, but to the 44th clocked
in task. Similarly for [d]efault and [i]nterrupted.

The function first adds (?c . marker-to-current-task) to the sel-list,
then goes through org-history and uses 0-9 and A-Z and then keeps going
through lower case letters without caring about whether the letter was
already in there.


Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
cairo version 1.16.0)
 of 2020-08-27
Package: Org mode version 9.3 (release_9.3 @ 
/home/unhammer/PREFIX/emacs/share/emacs/28.0.50/lisp/org/)