Distinction between consecutive tasks

[Gleek]

Hello Matus,

Thank you for writing this package.

Is it possible to add a small gap between consecutive tasks so that distinction can be made among them?

This is done in google calendar by always adding a pixel or two of whitespace in the end

This is not apparent when looking at the org-timeline view

The 10:30AM-12AM window in this case has two tasks in it, which isn't clear unless we hover on them.

I personally use two colors alternatively in my agenda view to create slight distinction in the agenda log.

Incorporating the gap would make it much cleaner, though I'll be happy to have the alternative color hack as well, in the case where implementing the former is very complicated :)

Thanks.

[aizensoosuke]

For now, pull request #19 implements a distinction by adding an overline on every other consecutive task.
I'm not sure it's possible to add a "small" gap (i.e. less than a whole block), but I might look into it later.
As for colors, that could be an option too. Maybe @Fuco1 has a preference.

This is how it looks with #19 :

Unfortunately putting boxes around blocks will not work, because emacs fuses them even if they are different colors. Putting a zero-width box around every other block almost works, but it still messes with the alignment and makes the timeline unreadable.

[Gleek]

Hey @aizensoosuke. Thanks for this

This is how it looks with #19 :

Interesting. For some reason the overline is hard to see in my case.
Although it's close to what I want after setting org-timeline-overlap-in-new-line and org-timeline-show-title-in-blocks to t

This is how 3 tasks are set

Unfortunately putting boxes around blocks will not work, because emacs fuses them even if they are different colors, and because it messes with the alignment:

Oh, I was thinking if we could somehow reduce the end time for the duration by a minute while rendering the block then we could get the desired result. This reduction should only happen when rendering that block and not when detecting the overlap.

So for this org file

* TODO Task1
<2021-03-03 Wed 10:00-11:00>
* TODO Task2
<2021-03-03 Wed 11:00-11:30>

If we change the end time for Task1 to 10:59 we will get a single character gap

You seem to be better equipped to answer if such an implementation is feasible.

[aizensoosuke]

Oh, I was thinking if we could somehow reduce the end time for the duration by a minute while rendering the block then we could get the desired result. This reduction should only happen when rendering that block and not when detecting the overlap.

This is possible, I'll implement it quickly as an option. The problem with this is that you won't be able to differentiate between blocks that last a whole hour and blocks that are a little than more 40 minutes. That is because each hour is divided into 6 blocks of 10min that can't be divided.

It will also delete very short blocks that would otherwise be rendered, but are directly followed by another block.

[aizensoosuke]

I'm letting you know that I implemented it. You'll have to setq org-timeline-space-out-consecutive to t. See #19

[aizensoosuke]

The way we're checking for overlaps makes this break org-timeline-overlap-in-new-line this will have to be fixed later. Hopefully this is good enough for you, for now.

[Gleek]

Great, it unfortunately didn't work for me

* TODO Task1
<2021-03-03 Wed 10:00-11:00>
* TODO Task2
<2021-03-03 Wed 11:00-11:30>

[Gleek]

I just noticed you pushed another commit. It seems to work with that. Thank you for the effort @aizensoosuke 😄. I'm impressed with your speed to implement this.

The only issue that now remains for me it seems is that the blocks don't perfectly align with the time slots. Maybe I should create another issue for this.

The Task1 task, for example in the screenshot above, starts exactly at 10:00AM but it seems as if it starts slightly before that.

[aizensoosuke]

Not really, what I did makes all the starting times shift.

The only issue that now remains for me it seems is that the blocks don't perfectly align with the time slots. Maybe I should create another issue for this.

Yes, I'm fixing this, I should push the fix in a couple minutes.

[aizensoosuke]

I'm impressed with your speed to implement this.

Thank you! I happened to need the exact same thing you needed just today, so I was already working on it anyway. I noticed your issue only after.

Thank you for the effort @aizensoosuke

Glad to help!

It should be working by now 👌

[Gleek]

It should be working by now 👌

Do you mean the alignment of blocks in timeslots? That still doesn't seem to work for me, if that's the case.

The gaps work perfectly for me though. 👍

[aizensoosuke]

Do you mean the alignment of blocks in timeslots? That still doesn't seem to work for me, if that's the case.

Did you use the last commit to #19?

If so, could you show me a screeshot?

[Gleek]

If so, could you show me a screeshot?

  |10:00
  Task1

should ideally look

  |10:00
  |Task1

[aizensoosuke]

The Task1 task, for example in the screenshot above, starts exactly at 10:00AM but it seems as if it starts slightly before that.

Oh sorry, we're talking about separate issues! I read too fast.

I had introduced a bug that shifted start times of blocks with my implementation of space-out-consecutive. That is fixed now.

What you're talking about is, indeed, a separate issue. We could probably change it by using a different character for the vertical separation of hours, but it would be pretty asymmetrical and I'm not sure that would please the eye.

|10:00
 Task1

This was a choice made by @Fuco1. I'll let him decide if he wants to keep it, but I think you're right. I'll implement that later, unless @Fuco1 has an objection.

[aizensoosuke]

I realized it was just 2 characters in the code, so here you go. See #19

[Gleek]

I realized it was just 2 characters in the code, so here you go. See #19

Awesome, it works fairly well. Although, the end moves 1 offset forward as well

It seems that the size needs to be shortened by a character to make it fit. I'll try to look into the code this weekend and see if I can make it happen locally. Will create a separate issue otherwise.

Anyways, thank for all the help.

[aizensoosuke]

Will create a separate issue otherwise.

This should probably happen at this point.

What you're asking for is that events fit in their slot only if they're one hour long and start at an o'clock time?
That would mean block length doesn't represent task length accurately anymore. As this is @Fuco1's project, he'll decide, but you should probably just fork this and add:

    (when (and (eq (mod beg 60) 0) (eq (mod end 60) 0))
                  (setq end-pos (- end-pos 1))
                  (setq block-length (- block-length 1)))

after line 442 of org-timeline.el.

[aizensoosuke]

So, to go back to the initial topic of this issue, I think having a separating character might make this clearer than it currently is.
After trying a lot of different unicode characters, I personally find this one to be nice:

But there is the issue of losing room for small task's titles.

Maybe just having the overline making consecutive events distinct is the way to go. @Fuco1