Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: Add tests for repeating task with +1d and +1h repeaters #750

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

munen
Copy link
Collaborator

@munen munen commented Nov 9, 2021

This adds working test for the recent fix from @tarnung (#746).

Unfortunately, adding the tests uncovered a problem with the test setup. Adding one more top headline into various_todos.org leads to an old test expectation to fail. I have already spent some time in trying to figure out what the problem is and haven't found it so far. However, I did find something that is peculiar and have added as XXX comment into the code.

If anybody is interested in this as well, I'd appreciate the help.

@munen munen force-pushed the test/tests-for-repeater-dot-plus branch from 94ef624 to 8b2cb80 Compare November 9, 2021 10:58
@munen munen added the help wanted Extra attention is needed label Nov 9, 2021
@@ -3,4 +3,13 @@
* This is not a todo
* TODO Task with active timestamp and repeater <2020-11-15 Sun +1d>
* TODO Repeating task
SCHEDULED: <2019-11-27 Wed +1d>
SCHEDULED: <2019-11-28 Thu +1d>
* TODO Repeating task with +1d repeater
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason why the expectation fails is this line. Adding another headline to various_todos.org after the * TODO Repeating task leads to the log drawer not to be build.

Unfortunately, the reason is unclear to me.

@tarnung
Copy link
Collaborator

tarnung commented Nov 9, 2021

Oh my.

This seems to be a parser error. It also exists on master.
Taking a note generates an entry in "logNotes" as it should. Parsing does not recognize the Note though and seems to handle it as regular Text. I can find the Note as a List in "description" and of course in "rawDescription".

To make the behaviour visible:

  • Take a note
  • Take another note
  • See how they are neatly arranged next to each other
  • Open and close "edit description" -> we have now lost the "logNotes"
  • Take another note
  • See how it is displayed visually separated from the other no longer recognized notes

Is it possible that something in your tests touches the description - thereby getting rid of the "logNotes"?

@tarnung
Copy link
Collaborator

tarnung commented Nov 19, 2021

Seems like it's not a bug after all.
Notes are ambiguous. They could be part of a valid description so the parser has to make a decison.
The decision here is to only parse notes if the parser can be sure they are notes. The behaviour is even documented in parse_org.js/_parseLogNotes.

// Only parse log notes if a logbook exists. Otherwise, a list - log notes
// or just a normal list - will go into the description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants