Calendar: current date is not being highlighted.

[sprnza]

Hi there!
I can't remember exactly the update I've started facing this issue but calendar's stopped highlighting the current date.
I use this code to attach the widget:

cal = lain.widgets.calendar({attach_to = {mytextclock}})

In a terminal cal returns the date highlighted properly.

Just tried a default awesom's config- it behaves the same way- no current date highlighting.

[lcpz]

Try this.

[sprnza]

It's already there. I've updated today morning.

[dummys]

Why closing the issue ? It's still not working right ?
Ohh you right, sorry :D

[sprnza]

@dummys it's another issue was closed. This one is not.

[lcpz]

It's already there. I've updated today morning.

Sorry, I mean try reverting to the previous code.

[sprnza]

@copycat-killer The previous code doesn't work either

[lcpz]

Is /usr/bin/cal --color=always the right command to have a colorized cal input in your distro?

For instance, if you're using Ubuntu, it's /usr/bin/cal -h instead.

EDIT: Or, maybe try setting cal = "cal", since you say it works for you.

[sprnza]

I use ArchLinux so --color=always is the option I should use. Either cal and cal --color=always returns the current date highlighted properly in terminal but nothing works properly in the calendar's notification.

[lcpz]

I'm on Arch too. This is what I use:

lain.widgets.calendar {
    cal = "/usr/bin/cal --color=always",
    attach_to = { mytextclock }
}

and it works (simple cal doesn't).

You can try adjusting the matching pattern in Lua:

$ lua
> cal = io.popen("/usr/bin/cal --color=always"):read("*a")
> cal:gsub("%c%[%d+[m]?%d+%c%[%d+[m]?", "DID I PICK IT?")

If you read the blurb, then it's working.

Of course, I'll work on a solution myself, but in the meantime you can test.

[sprnza]

It's working in lua, but not in Awesome, the calendar doesn't have the highlighting. I just tried a default config(with default theme) with your snippet added. It's not working.

[dummys]

Not working in my setup too.
Arch linux as well.

[2009]

This is broken for me now too even after adding cal = "/usr/bin/cal --color=always.
It looks like pattern didn't match my color codes that cal was producing.

    February 2017   
Su Mo Tu We Th Fr Sa
         ^[[7m 1^[[27m  2  3  4 
 5  6  7  8  9 10 11 
12 13 14 15 16 17 18 
19 20 21 22 23 24 25 
26 27 28  

I also had a problem with the icon not showing up because os.date was returning 01 instead of 1.
I created a pull request of what I did locally #303.

I think it would probably be better to change the pattern so it matches the output of the cal command without the --color=always option.

[sprnza]

Sorry for misleading comment:

$ lua
cal = io.popen("/usr/bin/cal --color=always"):read("*a")
cal:gsub("%c%[%d+[m]?%d+%c%[%d+[m]?", "DID I PICK IT?")

It's not being picked.

[sprnza]

code from the fix

cal:gsub("%c%[+%d+[m]?%s?%d+%c%[+%d+[m]?", "DID I PICK IT?")

does work in lua but highlighting is not appearing in Awesome's notification,

cal --color=always|less

    February 2017   
Su Mo Tu We Th Fr Sa
         ESC[7m 1ESC[27m  2  3  4 
 5  6  7  8  9 10 11 
12 13 14 15 16 17 18 
19 20 21 22 23 24 25 
26 27 28  

[fff0x]

It might be the locale settings which leads into showing the day of month without the leading zero. Therefor we also make sure that the "today" variable exclude it with:

local today = os.date("%e")

And then markup the right one:

ws = ws:gsub(today.." ", markup.bold(markup.color(bg, fg, today)))

The regex for the global substitution needs to be fixed ;-)

[lcpz]

@mbuelte You beat me on time. ;-)

[fff0x]

@copycat-killer, I'm afraid the regex still doensn't work (for me). Strangely enough that it match from the lua shell, but only if I append '--color=always' - it seems you've forgotten that in the latest commit.

> cal = io.popen("LANG=C /usr/bin/cal --color=always"):read("*a")
> cal:gsub("%c%[+%d+[m]?%s?%d+%c%[+%d+[m]?", "XX")
...
Su Mo Tu We Th Fr Sa
         XX  2  3  4 
...

> cal = io.popen("LANG=C /usr/bin/cal"):read("*a")
> cal:gsub("%c%[+%d+[m]?%s?%d+%c%[+%d+[m]?", "XX")
...
Su Mo Tu We Th Fr Sa
          1  2  3  4 
...

The only way of getting it to work is to set this crappy gsub:
ws = ws:gsub(today.." ", markup.bold(markup.color(bg, fg, today)))

Btw, this problem is independent from the current locale settings, I tried it with 'de_DE.UTF-8' and I got the same result.

[sprnza]

Doesn't for me either.
Upd: even if I change line 97 in calendar.lua to this
calendar.cal = "/usr/bin/cal --color=always"
I don't have the regex triggered.

[lcpz]

And of course it's working only for me.

Does pull #303 works for you?

[fff0x]

Unfortunately not

[fff0x]

How about such a solution? This may not be exactly nice, but it works for me:

...
local today = os.date("%e")
...
if(today:match("^%s%d")) then
  ws = ws:gsub(today.." ", markup.bold(markup.color(bg, fg, today)))
else
  ws = ws:gsub(today, markup.bold(markup.color(bg, fg, today)))
end
...

Edit: This works even if cal was run without --color=always.
@sprnza can you confirm this?

[lcpz]

Keep local today = os.date("%e") and try this:

-ws = ws:gsub("%c%[+%d+[m]?%s?%d+%c%[+%d+[m]?", markup.bold(markup.color(bg, fg, today)))
+ws = ws:gsub("%c%[%d+[m]?" .. today .. "%c%[%d+[m]?", markup.bold(markup.color(bg, fg, today)))

[fff0x]

Sorry, same problem, the regex won't match here :(

Edit: Hmm, probably there is another problem. Even this expression doesn't match: "%c%[7m"..today.."%c%[27m" - and it should. It seems I can't find these escape sequences in ws string. How can I print the whole 'raw' string?

Finally I'm pretty sure, that the string doesn't contain these escape sequences at all. First I thought it has something todo with helpers.async but even if I run cal with io.popen it won't match those regex based on the color sequence.

[lcpz]

Since it worked for you in the shell, are you sure you don't have an environment problem?

Try setting env in your cal command (or something related), and also set awful.util.shell to your shell, in your rc.lua, before calling lain.widgets.cal.

EDIT: You can use naughty.notify{text=ws, timeout=0} before ws:gsub(...) to print the pre-processing text.

[fff0x]

That's driving me nuts. I don't think there is an issue with the environment, everything looks similiar. I wonder, why the escape sequences doesn't came up in the output. Afterwards I wrote a little bash script that simulate the output of cal:

echo -e " Su Mo Tu We Th Fr Sa\n" \
  "         \e[7m 1\e[27m  2  3  4\n" \
  " 5  6  7  8  9 10 11\n"

And I see the escape sequences in the raw output, your regex matches and is highlighted as wished.

[lcpz]

I don't know. Did you try setting awful.util.shell?

Try to understand why this works on your system.

[sprnza]

Edit: This works even if cal was run without --color=always.
@sprnza can you confirm this?

Yep, the only working variant is one you suggested.

EDIT:

You can use naughty.notify{text=ws, timeout=0} before ws:gsub(...) to print the pre-processing text.

Actually I used this in helpers.lua inside the async function. It returns /usr/bin/cal --color=always for cmd and there is no the escape sequences in stdout.

[fff0x]

@sprnza That's the same I noticed here. When you try my bash script instead of cal it will show the escape sequences in the output. It seems somewhat ignores this kind of escape characters and others not.

I don't set awful.util.shell directly but it's pointing to /bin/bash and that's ok.

[sprnza]

@mbuelte Yep, your script is being processed just fine

[lcpz]

There's a problem with @mbuelte solution: it will highlight every today match. So if you have cal -w, or any other instance of os.date("%e") in you output, it will be highlighted.

Can you try setting cal = "bash -c cal" or something similar?

[sprnza]

Can you try setting cal = "bash -c cal" or something similar?
Doesn't work.

What I've found that if I pipe cal to a file, then convert it to a scipt and call it. It's being displayed properly. So it's cal who is misbehaving. It doesn't return escape sequences under awesome env.

#!/bin/bash
echo "    February 2017   
Su Mo Tu We Th Fr Sa
         ^[[7m 1^[[27m  2  3  4 
 5  6  7  8  9 10 11 
12 13 14 15 16 17 18 
19 20 21 22 23 24 25 
26 27 28            " 

[sprnza]

Even if I use

cal_output = io.popen("LANG=C /usr/bin/cal --color=always"):read("*a")

inside rc.lua (wich is working in lua shell) and then return the variable using awesome-client it doesn't have the escape sequences.

[sprnza]

awful.util.shell = "/usr/bin/bash" doesn't help

[fff0x]

Same here, even such things like cal --color=always | cat -v which shows the escape sequences in normal env, aren't shown within naughty.notify.

@copycat-killer could this depend on a library version? Any changes in naughty.notify that ignores this kind of escape characters?

Hm, forget the last one, this has nothing todo with naughty. Maybe we should try it with a vanilla awesome configuration.

[sprnza]

Works perfectly under Xephyr.

[sprnza]

Works perfectly if I start awesomewm using startx + xinitrc

[lcpz]

@sprnza What works perfectly? The standard lain.widgets.calendar or some patched version posted early?

How were you starting awesome before?

[sprnza]

The standard lain.widgets.calendar works like a rock from startx and doesn't using lightdm.

[lcpz]

@mbuelte How do you start awesome?

[sprnza]

adding TERM=linux in /etc/environment solves the "issue"

[fff0x]

Great! I'll try it out soon. I start awesome by xdg, but using startx doesn't solved the issue.

[lcpz]

@sprnza Can you try with cal = "TERM=linux cal --color=always" or cal = "/usr/bin/env TERM=linux cal --color=always" instead of modifying environment files?

[sprnza]

cal = "/usr/bin/env TERM=linux /usr/bin/cal --color=always"

this one works.

[sprnza]

@copycat-killer sorry for had being disturbing you with this unrelated issue. And thank you!

[lcpz]

@mbuelte Let me know if it works for you too.

I added a note in the wiki.

[fff0x]

@copycat-killer @sprnza Thanks a lot!

[dummys]

cal = "/usr/bin/env TERM=linux /usr/bin/cal --color=always"

This one works for me too !
thanks

[lcpz]

@mbuelte @sprnza @dummys

Is there a problem if I revert this change? It's not working for me.

[sprnza]

No problems with the reverting.

[fff0x]

No problem, thanks!

[sebras]

I'll quietly add this here to help the next person. It might be connected to your issue, but if not, don't mind me. :)

I encountered the issue of cal in the terminal not highlighting today's date on one of my computer, but did on another one. Which searching for a solution I came across this discussion. For me your suggestion --color=always is viable since it is not an option that exists in cal on Debian. Continuing searching revealed a similar discussion, which led me to this bug that was fixed by this commit in the ncal package in Debian. The solution for me was to put alias cal="if [ -t 1 ] ; then ncal -b ; else /usr/bin/cal ; fi" in my .bashrc which gives expected output for scripts, e.g. cal | cat and expected output for humans cal.