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

Implement PLANNING line support #314

Open
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

FlorianMickler
Copy link

Hi!

Since I wanted to keep some statistics about closing ToDo Items I needed a mechanism to record the closing-date.
While at it i implemented the "PLANNING" Line as described here: https://orgmode.org/worg/dev/org-syntax.html#Clock,_Diary_Sexp_and_Planning

This is a revised version with fixed testing and more relaxed DATE Parsing.

Best regards,
Flo

setting of SCHEDULED:  and DEADLINE: Keywords
heading.scheduled_date, heading.closed_date and heading.deadline_date should
always be of OrgDate (or OrgDateTime) type.
according to
https://orgmode.org/worg/dev/org-syntax.html#Timestamp

the dayname field can be pretty much anything. And indeed in german
locale setting the dayname is abbreviated with 2 letters only
also make the mappings somewhat easier to remember by having the p in
front mean calendar selection and having the s in front does mean cmdline
 selection.
Manage the Plannings-Line CLOSING: Keyword
When the TODO State changes from Done to not Done or vice versa
so the fix is, that we save a list of matches instead of a reference to the iterator
The line=None case was broken. It turns out, that it works better,
if line is empty string per default.
We do test heading parsing and not date-time parsing, so these cases should be enough.

Sorting should ignore inactive dates -> test added.
according to:
https://orgmode.org/worg/dev/org-syntax.org.html

there are only a few restrictions on the DAYNAME part. (Which is wise for other locales).
So <2011-08-29 mon> is a valid date.
Allow missing day, because it is a reasonable human readable date form and we should probably brake no viable usecases with this.

According to current formulation of the timestamp spec, a Date without Time is not valid anyway.
-> pt_br Locale day-names were changed to lowercase letters in this commit:
https://sourceware.org/git/?p=glibc.git;a=commit;h=686db256f640372df81242bf20d458f54e069f56
@FlorianMickler
Copy link
Author

Test failures is due to old glibc on Travis.
With current Fedora 29 glibc (glibc-2.28-26.fc29.x86_64) all tests pass. (See commit e05f4f3)

The pt_BR locale had the weekday capitalization changed [1]. That means that depending on libc version (-> Travis build tests vs Fedora 29) the test either was successull or failed [2].

[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=686db256f640372df81242bf20d458f54e069f56
[2]: commit e05f4f3

re commit e05f4f3
@codecov-io
Copy link

codecov-io commented Feb 11, 2019

Codecov Report

Merging #314 into master will decrease coverage by <.01%.
The diff coverage is 76.57%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #314      +/-   ##
==========================================
- Coverage   84.38%   84.38%   -0.01%     
==========================================
  Files          49       49              
  Lines        6794     6902     +108     
==========================================
+ Hits         5733     5824      +91     
- Misses       1061     1078      +17
Impacted Files Coverage Δ
tests/test_liborgdate_parsing.py 99.44% <100%> (+0.04%) ⬆️
ftplugin/orgmode/liborgmode/orgdate.py 91.4% <100%> (+0.13%) ⬆️
ftplugin/orgmode/vimbuffer.py 71.97% <100%> (+0.74%) ⬆️
tests/test_libheading.py 98.85% <100%> (-0.04%) ⬇️
ftplugin/orgmode/liborgmode/dom_obj.py 63.63% <100%> (+0.13%) ⬆️
tests/test_liborgdate_utf8.py 97.05% <100%> (ø) ⬆️
ftplugin/orgmode/_vim.py 57.51% <48.14%> (-0.75%) ⬇️
ftplugin/orgmode/plugins/Date.py 81.96% <56.52%> (-3.31%) ⬇️
ftplugin/orgmode/plugins/Todo.py 67.51% <68.75%> (+0.14%) ⬆️
ftplugin/orgmode/liborgmode/headings.py 86.52% <82.85%> (+1.78%) ⬆️
... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5099025...984df1a. Read the comment docs.

@XVilka
Copy link
Contributor

XVilka commented Jul 23, 2019

Would be nice to have this merged.

@tbm
Copy link
Contributor

tbm commented Jul 10, 2020

@FlorianMickler thanks for working on this. I'd love to see this merged.

There's a merge conflict now. Can you update your PR.

@jceb any comments on this PR? this would be really helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants