Uneven tab application per calendar in `khal calendar`

[7596ff]

I am using the {tab} character in my agenda_event_format: "{calendar-color}{cancelled}{start-end-time-style}{tab}{title}{repeat-symbol} {reset}{calendar}{reset}", and here is my output.

[cassie@houndoom ~]$ khal calendar -a Calendar -a Classes
    Su Mo Tu We Th Fr Sa     [2020-02-05] Today
Feb 26 27 28 29 30 31  1     |->  Vivian Visits Calendar
     2  3  4  5  6  7  8     10:00-10:50    PHL-1100-102 LOGIC I (R) Classes
     9 10 11 12 13 14 15     11:00-11:50    RC-2001-120 INTR WRITING ACROSS CURRICULUM (R)
    16 17 18 19 20 21 22     Classes
    23 24 25 26 27 28 29     14:00-14:50    AST-1002-102 INTRO AST II/STAR GALAX (R) Classes
Mar  1  2  3  4  5  6  7     15:30-16:45    PHL-2000-104 PHILOSOPHY, SOCIETY & ETHICS (R)
     8  9 10 11 12 13 14     Classes
    15 16 17 18 19 20 21     17:00-18:00  Pay Ticket Deadline Calendar
    22 23 24 25 26 27 28     22:00-23:50    AST-1002-206 Laboratory (R) Classes
Apr 29 30 31  1  2  3  4     [2020-02-06] Tomorrow
     5  6  7  8  9 10 11     ->|  Vivian Visits Calendar
    12 13 14 15 16 17 18     09:30-10:45    PHL-1501-101 MIND, KNOWLEDGE & REALITY (R) Classes
    19 20 21 22 23 24 25     11:00-14:00  Rivers Street (noodles) (R) Calendar
May 26 27 28 29 30  1  2

This is easier to read in a screenshot, posted here.

While the duration formats are the same length on different events, it seems that depending on the calendar there are different tab lengths applied to each event.

Despite the intended function of the tab control code, I would love to be able to format the list in some sort of column-based output, so that I could have a column each for time, summary, and calendar name. I await the discussion in this issue.

[7596ff]

With more calendars in view, there seem to be proceedingly more extra tab characters, in a 1-for-1 relationship.

[d7415]

I've been able to reproduce, though I have no idea why it's happening. One weird observation that may be useful: for me, inserting a {nl} before the {tab} in your string makes my events consistent and doesn't add a newline...

[d7415]

Ok, it looks like it's only in the calendar view. list doesn't appear to be affected.

[ephase]

Hi, I've been able to reproduce the issue too. This is related to color : if two calendars share the same color, the alignment is correct but if color is not the same, problem occurs.

With some tests, i isolate re responsible of the bug :

def color_wrap(text, width=70):
    """A variant of wrap that takes SGR codes (somewhat) into account.

    This doesn't actually adjust the length, but makes sure that
    lines that enable some attribues also contain a RESET, and also adds
    that code to the next line
    """
    # TODO we really want to ignore all SGR codes when measuring the width
    lines = wrap(text, width)
    for num, _ in enumerate(lines):
        sgr = find_unmatched_sgr(lines[num])
        if sgr:
            lines[num] += RESET
            if num != len(lines):
                lines[num + 1] = sgr + lines[num + 1]
    return lines

on utils.py line 79

[ephase]

I've got it, i made a modification for lines = wrap(text, width) :

lines = wrap(text, width, expand_tabs=False, replace_whitespace=False)

I've got some errors on unit test, so I need to investigate a little.

[ephase]

@7596ff I submit a PR for the issue, but you can use str.format() properties to align elements, for example :

agenda_event_format = {calendar-color}{cancelled}{start-end-time-style:12}}{title}{repeat-symbol} {reset} {calendar}{reset}

{start-end-time-style} will take 12 column with the :12 option, then {title} will be aligned

[7596ff]

Whoa, this is awesome. thank you so much

[ephase]

@7596ff My PR introduce a bug, I need to work on it. But {[...]:<rows>} seems to work like a charm.

[geier]

@ephase can you remember, what kind of bug your solution introduces?

I can best reproduce this, if I use different types of colors for different calendars. E.g. I use "dark red" for one calendar, and "#FF00FF" for another calendar. Those produces escape codes of different lengths and therefore the tab expansion failes.

khal list is not affected, because we don't need to wrap lines there.

[geier]

I'm actually not sure if it's really a bug. khal keeps the tab where it is, it's probaly the calculation of the terminal emulator that doesn't remove the length of the escape sequences when calculation how long to display the tab.

EDITED

[d7415]

FWIW ephase's PR was #907.

[geier]

@d7415 which works fine for me.