due date and threshold selection fields makes wrong edits when main text input has been filled with Friendly/Speaking date names

[swantzter]

Bug Report

IMPORTANT:
Please follow this template strictly when reporting bugs. Providing detailed and accurate information helps the development team to understand and address the issue effectively.

App Version: 2.0.0-dev14

Platform: Windows

Installation Method: Direct Download

Bug Description:
[Provide a clear and concise description of the bug you encountered.]

Steps to Reproduce:

1. Open the dialog to create a new task
2. Write "(A) Test due:next friday"
3. Change the due date using the date input field below to "2023-09-30"

Expected Behavior:
The input field will read "(A) Test due:2023-09-30"

Actual Behavior:
The input field reads "(A) Test due:2023-09-30 friday"

Additional Information:

Screenshots:

System Information:

• OS Version: Windows 11
• Processor: Intel Core i7
• RAM: 32GB
• Graphics Card: NVIDIA GeForce GTX 1650 Ti

Reproducibility:

• Always

Impact:

• Moderate

Workaround:
You can manually edit the main field to remove "friday" after changing the due date

[ransome1]

@swantzter should be fixed in https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev15. Could you please check the release?

[swantzter]

This is not fixed in -dev15 as far as i can tell, following the reproduction steps above still results in "(A) Test due:2023-09-30 friday" instead of "(A) Test due:2023-09-30"

[ransome1]

You're right, it hasn't been fixed for the case you described in the initial report. It has been fixed for the case, where the todo already existed and within the inline date pickers in the todo table.

Fixing the described case (which seems like an edge case to me) will need significantly more effort on my side. Which I can't put into it, since there is plenty of other things to finish up. It's possible this won't fix or need to be picked up by someone else. Hope you understand.

[swantzter]

Yup, I wasn't expecting this to necessarily be a first 2.0 release fix :)

I imagine what you'd basically have to do is unless due: is followed by YYYY-MM-DD you'd have to keep chomping either to find the widest possible, or a reasonably max wide thing that Sugar accepts as a valid date, realising that there might be states where it goes from valid->invalid->valid as you chomp

[ransome1]

I imagine what you'd basically have to do is unless due: is followed by YYYY-MM-DD you'd have to keep chomping either to find the widest possible, or a reasonably max wide thing that Sugar accepts as a valid date, realising that there might be states where it goes from valid->invalid->valid as you chomp

Like this it is already implemented on the backend side (electrons main process). But in order to adapt this code in the frontend (Electrons renderer process) as well, a couple of things would need to be refactored to avoid duplicate logic.

[rzw]

I would suggest making it a habit to write friendly dates without space.

[ransome1]

I would suggest making it a habit to write friendly dates without space.

This would make my life as developer significantly easier ;)

But it is most likely not what the common user would be willing to accept. Also the library responsible for the speaking date detection (called Sugar) is not capable of detecting speaking dates without spaces.

In order to solve the issue at hand, I simply need to prioritize this at some point.

[rzw]

This would make my life as developer significantly easier ;)
That's what I thought.

Also the library responsible for the speaking date detection (called Sugar) is not capable of detecting speaking dates without spaces.
Are you sure? I wouldn't have posted it if my tests hadn't worked fine. Of course I didn't test all but "in2days" works just as well as "in 2 days"

But it is most likely not what the common user would be willing to accept.
Well, my impression is that it works either way. So it's just for the people that complain ;-) (I'm not being serious here)
No, you could call it a better work around for people anticipating that they will fiddle around with the due date at some time, which moves this issue further down in the priority list.

[ransome1]

Are you sure? I wouldn't have posted it if my tests hadn't worked fine. Of course I didn't test all but "in2days" works just as well as "in 2 days"

Nope, not sure. And you seem to be right, Sugar is really accepting this :D

[github-actions]

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.