`Xmonad.Hooks.StatusBar.PP` lacks options in `xmobarBorder`
nils-trubkin opened this issue · comments
Hi,
I can not find a whole lot of documentation on this one, so if anyone could point me in the right direction, I'd appreciate it a lot.
So basically, according to various configs found online (DT config), but most importantly the Xmobar.X11.Parsers, there do exist extra options for the margin of the box. The mb, mt, ml and mr to be exact. The Parsers file is now missing from the xmobar git, so most likely it's using something else, nonetheless the options are still supported.
Upd: Yeah it was just moved to Xmobar.Run.Parsers
Would it make sense to add those options to the xmobarBorder?
Does anyone know what parser is used, and maybe could point me to it?
It's a bit of a hack but you can specify these within any of the input strings, as long as they are not the first value; e.g.
xmobarBorder "Top mt=2" "#ffffff ml=3" 2
is equivalent to
\input -> "<box type=Top mt=2 width=2 color=#ffffff ml=3>" <> input <> "</box>"
which should be exactly what you want. I'm not sure it's worth adding this as an explicit option, since we would need to change the type signature (and thus it would be a breaking changing)
We could also add xmobarBorder' or xmobarBorderMargins or something. Breaking the API for this isn't worth it, but having some API for this might be worthwhile.
I kinda hate that we use strings as arguments (yes, I know I was the one who added xmobarBorder) but it saves us the overhead of tracking xmobar's API for changes... Maybe we can add an XMobar module that uses union types as arguments instead of strings?
It's a bit of a hack but you can specify these within any of the input strings, as long as they are not the first value; e.g.
xmobarBorder "Top mt=2" "#ffffff ml=3" 2is equivalent to
\input -> "<box type=Top mt=2 width=2 color=#ffffff ml=3>" <> input <> "</box>"which should be exactly what you want. I'm not sure it's worth adding this as an explicit option, since we would need to change the type signature (and thus it would be a breaking changing)
Yes, I understand that is possible to do. Thank you for the tip. I was just thinking that since the function for generation of the syntax it exists, it should support all the options. It is, as you called it somewhat of a hack, and is not as neat as using the function.
We could also add
xmobarBorder'orxmobarBorderMarginsor something. Breaking the API for this isn't worth it, but having some API for this might be worthwhile.
Definitely adding adding the extra function is a better option, I had something similar in mind.
I kinda hate that we use strings as arguments (yes, I know I was the one who added xmobarBorder) but it saves us the overhead of tracking xmobar's API for changes... Maybe we can add an
XMobarmodule that uses union types as arguments instead of strings?
I doubt there will be much change in terms of the strings themselves. The union situation you mentioned does sound like a more neat, haskell-style solution.
On Tue, May 17 2022 03:08, Yecine Megdiche wrote: Maybe we can add an
XMobarmodule that uses union types as arguments instead of strings?
If we really commit to type nonsense we could use open unions (mostly implemented via type level lists). Then new additions to the xmobar API would be easy to add
Might be better to just tell people to depend on the xmobar package and use its own data types…
(I've been doing this for a while because I wasn't comfortable using UnsafeXMonadLog with anything else than xmobar's own stripActions; I do have to patch xmobar's cabal file to expose modules but this shouldn't be difficult to upstream)