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 an equivalent of org-agenda-start-on-weekday #266 #676

Merged
merged 3 commits into from
May 12, 2021

Conversation

tomonacci
Copy link

@tomonacci tomonacci commented May 12, 2021

WISOTT. One caveat is that I changed the default start of the week to Monday from Sunday to align with the default in Org to minimize surprise for people coming from Org (at the expense of surprising longtime Organice users).

Controls in the settings:
Screen Shot 2021-05-12 at 3 18 05 AM

tomonacci added 3 commits May 12, 2021 02:39
- Stop using null to mean org-agenda-start-on-weekday = nil because it
  is very confusing. -1 was chosen instead because it is a number.
- On mobile, three-letter week names are too long. Now the week names
  only get one character each.
Copy link
Collaborator

@schoettl schoettl left a comment

Choose a reason for hiding this comment

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

Nice! I like the new default Monday, especially if it's the default in org mode.

It would be great if you could add tests to prove the settings control works.

return {
files: determineIncludedFiles(allFiles, fileSettings, path, 'includeInAgenda', false),
todoKeywordSets: file.get('todoKeywordSets'),
agendaTimeframe: state.base.get('agendaTimeframe'),
agendaDefaultDeadlineDelayValue: state.base.get('agendaDefaultDeadlineDelayValue') || 5,
agendaDefaultDeadlineDelayUnit: state.base.get('agendaDefaultDeadlineDelayUnit') || 'd',
agendaStartOnWeekday: agendaStartOnWeekday == null ? 1 : +agendaStartOnWeekday,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why not ===? I thought it's best practice to use it instead of ==. Why the +? To convert to integer?

How far do we trust the state store in terms of data integrity? The existing lines above this one don't check the types. So I think we better stick to that scheme. @munen what do you think?

Copy link
Author

Choose a reason for hiding this comment

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

Right, triple equals is best practice in general but some consider double equals against null and undefined to be an exception since it’s a convenient way of eliminating both at once. Yes + is for number conversion (maybe this was too hacky)

I’m type checking here because falseness check interferes with 0... I’ll comment more on that in #677

return {
fontSize: state.base.get('fontSize') || 'Regular',
bulletStyle: state.base.get('bulletStyle'),
shouldTapTodoToAdvance: state.base.get('shouldTapTodoToAdvance'),
agendaDefaultDeadlineDelayValue: state.base.get('agendaDefaultDeadlineDelayValue') || 5,
agendaDefaultDeadlineDelayUnit: state.base.get('agendaDefaultDeadlineDelayUnit') || 'd',
agendaStartOnWeekday: agendaStartOnWeekday == null ? 1 : +agendaStartOnWeekday,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same question as above, here.

@munen
Copy link
Collaborator

munen commented May 12, 2021

Hi @tomonacci

Thank you for your contribution 🙏

@schoettl Thank you for the code review 🙏

I've looked through the code. It works well, but I'd make some changes. I'll pull PR into the develop branch and make a new PR from there against master with changes that I propose. Feel free to make comments there.

I haven't written a test, yet. If you can do so, as @schoettl suggested, that would be nice^^

@munen munen changed the base branch from master to develop May 12, 2021 11:30
@munen munen merged commit dd09812 into 200ok-ch:develop May 12, 2021
@tomonacci
Copy link
Author

Thanks for the review @schoettl and @munen! Regarding tests, let me know if you have a specific existing test case for a setting control that you want me to mimic the format/style of, otherwise I’ll look around and try my best

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.

3 participants