Change default formatting?

[ammgws]

Pretty sure this is also #1231 and was added with the new formatting system.

Have a look there to see the right way to format the value.

@MaxVerevkin seems to me like the new behavior might not be a very good default, we might want to have a look at that. (See also #1272)

Originally posted by @GladOSkar in #1303 (comment)

I have a few ideas:

* We can just change the default "min-width" to 1, however those who relied on defaults might get confused.

* We can also add "refer to (...) for more info" in the blocks' docs. And perhaps formatting docs can be rewritten in a more clear way?

* (not an actual option) Maybe not provide the default value for "min-width" at all?

_Originally posted by @MaxVerevkin in #1303

[GladOSkar]

Option 4 i see and my favorite solution would be to do what's asked in (the second part of) #1272 and allow a number format as discussed in #240 and implemented in #704 that can have a fixed width and still not show any gaps, even if it's sometimes a bit suboptimal in the number of significant digits shown.

That might be difficult to enable with the current placeholder syntax, but is probably possible. Alternatively we could also just change the default. I'll propose something when i have time

[ram02z]

Not sure if this entirely relevant, however, blocks like the brightness block don't have a format key, which makes sense, but that means it can't make use of the formatting available in other blocks. Not sure if it worth adding the format key just so I can change the min_width of the brightness block to 3 though.

[MaxVerevkin]

Not sure if it worth adding the format key just so I can change the min_width of the brightness block to 3 though.

I think it does.

[GladOSkar]

Yeah now that we have the universal logic that's not an issue. Plus it will provide additional options like showing the brightness as a bar. But i wouldn't consider that relevant to this issue, feel free to open another one :)

[GladOSkar]

Option 4 i see and my favorite solution would be to do what's asked in (the second part of) #1272 and allow a number format as discussed in #240 and implemented in #704 that can have a fixed width and still not show any gaps, even if it's sometimes a bit suboptimal in the number of significant digits shown.

That might be difficult to enable with the current placeholder syntax, but is probably possible. Alternatively we could also just change the default. I'll propose something when i have time

I thought about this a bit again and realized it's only possible for value placeholders with a min_width of at least 4 characters, since without padding a value like 42000 can't really be displayed with 3 value characters in any nice way: 42.K / .04M would be the only (ugly) solutions i can come up with.

Starting at 4 characters we can easily do something like what was discussed in the other issue:

4.20M
0.42M
42.0K
4.20K
0.42K

Now i'm not sure if it's worth the effort/complexity just for avoiding some ugly padding, but we probably could add this as a special case for min_width >= 4 in the default behavior of the value formatter.

What do you think @MaxVerevkin?

[MaxVerevkin]

I still don't like when 420K is displayed as 0.42M but I can understand that it might not be the case for others.

but we probably could add this as a special case for min_width >= 4 in the default behavior of the value formatter

No, I think setting min_width to, say 5, sould do what it does now. However, I think we can either add some kind of config option or just set your proposed solution as the default and disable it if min_width is set (edit: no, I forgot that your solution also uses min_width).

And actually, 42.K doesn't look that bad for me.

[MaxVerevkin]

Okay, perhaps it's time to reconsider the formatting "subsystem". When choosing between verbosity and shortness we've chosen shortness. Was this a good choice?

Formatting configuration is already sort of messy, but it will be even worse it we'll add more options (like how to choose between "always N digits" and engineering notation, no one have proposed anything yet).

Looking back at the work done by @remi-dupre, #750 (comment) looks quite interesting. I can imagine doing something like this:

"{<var>@num-const-digits(<params>)}" # Use "always N digits" formatter
"{<var>@num-eng(<params>)}" # Use engineering notation
"{<var>@num-bar(<params>)}" # Draw a bar (not related to this issue, but looks cool)
"{<var>@str(<params>)}" # String formatter
"{<var>@str-rotating(<params>)}" # Rotating string (would be really cool to have such functionality)

Yes, those are breaking changes, and most likely it will not be a solution in the near future, but still.

@ammgws @GladOSkar @remi-dupre your thoughts?

[GladOSkar]

Yeah i had originally vouched for shortness as well and still prefer it. And although i kinda like your suggestion, I'd prefer not to break configs again. I wonder if there's a way to do this within the confines of currently valid syntax? Something like another "modifier" character to specify the formatter?:

{<name>[!<fix|eng|bar|str|rot>]...

With the default being either fix for fixed width or eng for engineering notation, with all the old options still working.

Granted, we'd be keeping a lot of dead syntax around, but maybe it's not that bad? Unsure about this, you probably know better given you wrote the formatter

[MaxVerevkin]

In addition, I would also like to bring up two more issues:

• There is no way to handle missing keys. Currently, in cases when keys may by missing we provide many formatting options, like format, format_missing and so on.
• Currently, some placeholders may have different types. The bad thing is, it's not possible to set different options for different types. And what's more important, there is no way to change the surrounding spacing for different types. This one isn't solved yet and it's impossible to solve without breaking changes.

Lets imagine that current formatting system is not yet implemented. Now, I would propose something like this:

Format <var> with engineering notation and surround it with spaces. This structure will resolve to nothing if <var> is missing or <var> is not a number.

{ <var>.eng(<params>) |}

Format <var> with fixed digits formatter and prepend num: before it. If <var> a string instead of number, it will be prepended with text: . If <var> is missing, N/A will be printed.

{num: <var>.fix(<params>)|text: <var>.str(<params>)|'N/A'}

While it's more verbose, It's way more flexible. This can be partially (without the typing part) implemented without breaking compatibility (well, it will break stuff if | is used in the config).

[GladOSkar]

I like it. You've convinced me. Seems pretty well thought through.

One detail question: Do you intend to delimit the variable name? Or is it distinguished from the literal text in another way? In other words, would you literally write {volume: <volume>.fix(3)|} or {volume: volume.fix(3)|}? For the latter maybe the dot is what makes it a variable, which would require something like \. to actually print a dot in the literal text.

I prefer delimiting either the variable or the literal text over using the dot

[MaxVerevkin]

Do you intend to delimit the variable name?

I don't have a strong opinion on this one, but using <> will make parsing easier.

I was also thinking about using single quotes (the parsing is still simple) for literal text but it seems to be messy.

[MaxVerevkin]

Also two more details:

---

How exactly should arguments be represented? For example, in {volume: <volume>.fix(3)|}, 3 is width, but how to pas minimal prefix and unit? One of the options is python-like parameters:

{speed: <speed>.fix(3,unit=_b,prefix=+K)|}

The second option is to use something similar to what we have now (note: + is not currently implemented, it forces the prefix instead of setting the minimal prefix):

{speed: <speed>.fix(3*_b;+K)|}

Again, tradeoffs between shortness and verbosity must be taken. But the first one is much more readable, isn't it?

---

Should integers and floats be distinguished? Currently they are, sort of.

[GladOSkar]

How about just positional arguments? Like:

{speed: <speed>.fix(3,_b,+K)|}

that way we loose the ability to eg. set the prefix without setting the unit, but if the order is thought through enough and the defaults are documented, i think it'd be fine while not being overly verbose.

Regarding floats vs. integers: currently, the differentiation is made to make sure units like bits never get the lower SI prefixes (a microbit probably only makes sense probabilistically). But if the formatting syntax is well designed i don't think the differentiation is necessary. Unless you see something else.