Ignore additonal TODO types

[wpfan1000]

Hi,
I added additional TODO types such as WAITING.
So I may have a heading:

• WAITING Expect mail

toc-org includes the WAITING todo type in the table of contents.

I notice that toc-org does not include eg TODO.

When I click on

• WAITING Expect mail

in the table of contents, I get an error:

No match - create as a heading?

I assume because toc-org includes WAITING in the heading name, while org mode ignores WAITING in the heading name, and so there is a mismatch.

Is there a way to ignore additional TODO types?

Thanks ahead of time.

[snosov1]

Sorry, I'm not sure I understand your message 100%. Can you, please, provide

1. Example file
2. A sequence of actions that you execute
3. Expected behavior
4. Behavior that you see

[wpfan1000]

Hi,
Thanks for your support :)
I sent a test email to you - please let me know if you did not receive it.

[wpfan1000]

Also I have one other issue......

If I have a heading tagged with :TOC: then sometimes the first entry in the table of contents is on the same line as the TOC headline.

Eg if i have:

• Headline 1...

• Table of contents... :TOC:

• Headline 2...

Then toc-org displays the table of contents like this:

• Table of contents :TOC:... - Headline 1

• Headline 2

[snosov1]

I sent a test email to you - please let me know if you did not receive it.

Unfortunately, I didn't get any e-mail - and I'd advise to use this thread, anyhow.

If I have a heading tagged with :TOC: then sometimes the first entry in the table of contents is on the same line as the TOC headline.

This is a known presentation issue. Functionally, it works alright (i.e. the contents of the file are correct) - it's only the presentation that's affected (and only when the contents of the TOC change). The workaround is to open/close it. Implementing it properly seems to be too difficult compared to its value (see #9)

[wpfan1000]

Thanks for letting me know about the presentation issue and the work around.

Getting back to the first issue, you asked me how to reproduce it.

If you put the following in a .org file you should be able to reproduce this - please let me know if you can't:

#+TODO: TODO(t) WAITING(w) GOAL(g) ISSUE(i) ABANDONED(a) RESOLVED(v) NFG(n) | DONE(d)

* WAITING Test

* TOC :TOC:
- [[#waiting-test][WAITING Test]]

On the first line i have defined some additional TODO types

On the second line I have made the heading * Test to be of a WAITING type (I use C-c C-t to bring up a selection of TODO types and then choose 1)

On the third line I have a heading called * TOC and I have tagged it "TOC:

The problem is this:

Clicking on:

• [[#waiting-test][WAITING Test]]
  Gives the error:
  No match - Create this as a new heading?

I believe this is due to toc-org thinking that WAITING is part of the name of the heading, while org mode ignores WAITING as part of the heading name, because WAITING is a TODO type.

Similarly:

* WAITING Test

* TOC :TOC:
- [[#waiting-test][WAITING Test]]
- [[#todo-test2][TODO Test2]]

* TODO Test2

Also gives the same error for Test2

IMHO toc-org needs to strip out the TODO keyword out of the link in order for the link to work.

I hope this explains things well enough, please let me know if not.

[quarkquartet]

I'm having the same issue.

Basically, what I have is:

* toc :TOC:
  - [[#canceled-a-head1][CANCELED [[#A]] head1]]
  - [[#head2][head2]]
* CANCELED [[#A]] head1
* DONE [[#A]] head2

As you can see, if there is a keyword "DONE" on the heading (e.g.head2 above) which is the default for emacs org-mode, the inserting function of toc automatically recognize it, and gives me a great link in the toc section with the correct name. However, if the todo keywords is self-defined, i.e. "CANCELED" in head1 above, it cannot recognize it, and simply regards it as part of the section title. What I want is this:

* toc :TOC:
  - [[#head1][head1]]
  - [[#head2][head2]]
* CANCELED [[#A]] head1
* DONE [[#A]] head2

Looking forward to your reply.

[kyzyl]

Did anything ever happen with this? As far as I can tell this is still an issue. If the user has any org-todo-keywords defined which are not the "default" (not sure where this package gets defaults), the TOC inserts the keyword as part of the heading, which causes org to prompt the user to create a heading when the follow the link.

[wpfan1000]

I have presumed since the developer did not respond to either of us, for over 2 years now, that he has chosen to ignore us and the issue.

[snosov1]

Guys, you're always on my mind!

As for the issue, Github has no access to individual org-todo-keywords variables. If we start treating it by the mode - it will break links on GitHub. Also, different people might have different values in their setup which will lead to inconsistencies.

So, all the metadata should be part of the file itself (not in emacs config). And not only that - it should be parsed by the github org renderer .

One way to do this is via per-file keywords

[kyzyl]

For anyone who is mostly using org-mode, I hacked together a custom hrefifier to strip out any TODO keywords in org-todo-keywords, excluding | and ignoring the keyword shortcuts. This code probably breaks in a bunch of scenarios, and doesn't handle file-level TODO keywords, but it's a starting point.

(defun toc-org-hrefify-todo (str &optional hash)
    "Strip TODO keywords from the input heading and then format as an org link."
    (toc-org-format-visible-link (strip-todo-keywords str)))

(defun strip-todo-keywords (heading)
    "Strip leading TODO keywords from an input heading."

    ;; Strip off TODO shortcut characters from the keywords list,
    ;; and remove the "|" state separator if present.
    (setq org-todo-keywords-stripped
        (mapcar
        (lambda (str)
            (replace-regexp-in-string "([^()]+)" "" str))
            (cl-remove "|" (cdr (car org-todo-keywords))  :test #'equal)))

    ;; Strip any keywords from the beginning of the heading.
    (let ((regexp (format "^\\(%s\\)[[:space:]]+" (regexp-opt org-todo-keywords-stripped 'words))))
        (if (string-match regexp heading)
            (replace-regexp-in-string regexp "" heading)
            heading)))

Now in your org file you can tag your table of contents heading as :TOC_1_TODO: and the links should then work correctly. In my case I also added (setq toc-org-hrefify-default "todo") to my config, after which I can just tag the heading :toc: and it will work correctly in org-mode. Of course, as pointed out above this will not work correctly for markdown publishing on Github or elsewhere, so for that use case you would have to tag the TOC as :TOC_1_GH:.

Side note: It might be useful if the TOC tag could also be specified in the format :TOC_<style>:, as in :TOC_GH: or :TOC_TODO:. Right now it seems to only work if the depth number is in the middle: :TOC_1_GH:. Most people probably just set toc-org-max-depth and then override it when needed.

[snosov1]

I hacked together a custom hrefifier to strip out any TODO keywords in org-todo-keywords

Yup, that's why we love customization.

Most people probably just set toc-org-max-depth and then override it when needed.

Being toc-org maintainer I have zero idea how many people use that method (or what the hell they're even doing with the mode, generally). Sticking to the logic of "no metadata outside of the file itself" seems like a Good Idea™ to me and my suggestion for the users is to stick to it as well. Though, some will need to break out of this rule, like, you seem to - that's where the customization comes to the rescue.

[kyzyl]

For the record, my original position was that this is a package to auto-generate TOCs in emacs org files, so it should probably produce TOCs that work correctly in org-mode, especially when there is an "org" hrefifier option built in.

I get that we can't please everyone, nor can we anticipate all the ways people will use a system like emacs/org-mode. Nevertheless, it seems relatively safe to assume that many org users are using emacs, org-mode, and TODOs. This point is somewhat conceded by the fact that toc-org already handles the two default "TODO" and "DONE" keywords. Furthermore, most people who use emacs make at least light use of "outside of file" configs (yourself included, it seems). It's not really clear to me how this is a controversial position, but maybe I'm wrong and people are mostly using some VSCode extension and authoring their Github readmes.

However upon further reflection on the readme and your comments here, I decided that it wasn't my place to fight the "no config outside the file" or "Github first" philosophy.

In any case, I appreciate the easy escape hatch you built in. I do have a couple of questions, though:

1. Am I correct in assuming that toc-org-hrefify-org already produces links which do not work correctly on Github? In this case, what is stopping you from making the org variant make the links work correctly in org-mode? Once you're assuming org-mode, you can assume elisp/config access, so what is the use-case for org link rendering outside of org-mode?
2. My comment about toc-org-max-depth was not to make a statement about how people configure things, but to highlight that by requiring the depth number in the tag, you require the user to override the depth number if they want to switch the style on that heading. The desired TOC depth and the desired TOC style seem to be orthogonal parameters, but right now the user must explicitly set depth if they wish to set style (but not vice versa). Am I missing something here?

[manueldeljesus]

May it be enough to parse org-todo-keywords if it exists and add the state names to the custom-keywords variable?