Align key option about ojg HOT 11 CLOSED

So far it only aligns members of array that fit on a single line. I'll look into aligning map/object members.

from ojg.

Release v1.12.0 has the alignment of map members.

from ojg.

The align option is available in the align branch. Let know what you think.

from ojg.

Now on develop branch. Slated for release this weekend with a few other extras added.

from ojg.

OjG v1.8.0 has the align option. Similar to what you proposed but numbers are right aligned and other are left aligned.

from ojg.

Is it possible to achieve vertical alignment with your pretty tool in a simpler structure?

input json

{
"PersonA": 30,
"PersonB longer name": 40
}

preferred output

{
"PersonA"            : 30,
"PersonB longer name": 40
}

from ojg.

Thank you for looking into it, that would be a great formatting win for displaying simple config files

from ojg.

Thanks @ohler55 for implementing this feature and even remembering to add a notification to this closed issue!!!

Just as a further (albeit minor vs. the already implemented!) step to further perfection, would you feel like making the : colon separators aligned and/or separate?

I think these SEN outputs look more neat...
New1: with separators separated and aligned

applescript_enabled 	: ""
bundle_executable   	: Karabiner-VirtualHIDDevice-Manager
bundle_identifier   	: org.pqrs.Karabiner-VirtualHIDDevice-Manager
bundle_name         	: Karabiner-VirtualHIDDevice-Manager
bundle_package_type 	: APPL
bundle_short_version	: "1.22.0"
bundle_version      	: "1.22.0"

New2: with separators aligned, but not separated (maybe this would be better for more compact layouts not to have an extra separator)

applescript_enabled : ""
bundle_executable   : Karabiner-VirtualHIDDevice-Manager
bundle_identifier   : org.pqrs.Karabiner-VirtualHIDDevice-Manager
bundle_name         : Karabiner-VirtualHIDDevice-Manager
bundle_package_type : APPL
bundle_short_version: "1.22.0"
bundle_version      : "1.22.0"

...than this current output
Old:

applescript_enabled: 	""
bundle_executable:   	Karabiner-VirtualHIDDevice-Manager
bundle_identifier:   	org.pqrs.Karabiner-VirtualHIDDevice-Manager
bundle_name:         	Karabiner-VirtualHIDDevice-Manager
bundle_package_type: 	APPL
bundle_short_version:	"1.22.0"
bundle_version:      	"1.22.0"

from ojg.

I toyed with "New2" and "Old" but settled on Old more consistency with other non-aligned maps. I suppose consistency is in the eye of the beholder but my thinking was that all other map entries had the : immediately after the key so keeping it there assures that there is no question about whether there is a space in the key. Maybe not really an issue but the second reason was that it was easier to implement. Not by a lot but a little.

I'd like to take this to the discussion section (see the top of this page or just #65). I don't want to fall into the trap of providing too many options for different display format preferences. You can never satisfy everyone. I haven't thought it through yet but I think there might be some options to somehow use custom formatters without changing the underlying code in OjG. Something like a pipeline or maybe some plug-ins or something. Getting more folks involved in the discussion might help narrow down how that night be done.

from ojg.

there is no question about whether there is a space in the key

wouldn't the extra space require quotes just like so:

oj -p 80.1.1 -c -sen people.json
{
  PersonA:               30
  "PersonB longer name": 35
  PersonClongername:     40
}

I mean, it's the same question: "Is there a space at the beginning of the value?", to which the same answer "No, if there were, you'd see quotes" applies, no?

...easier to implement. Not by a lot but a little.

sure thing

I don't want to fall into the trap of providing too many options for different display format preferences.

Well, for my narrow use case of using your awesome cli tool to pretty-print json files in a terminal, that's a non-trap as long as I can stuff most of these options in a config file/env var (basically, also a config shell file)/or, worst case, in a shell alias function: I'll just put most of the formatting I'll always need (like pretty formatting with colors in a SEN format) and "forget" about them, only maybe adding 1 extra option manually from time to time when I need to adjust the width/depth values in the -p option

Of course, if you have grander plans that require more simplicity wouldn't want to entrap your project :)

from ojg.

You are right about the space in names.

The trap I was referring to is trying to keep up with requests for formatting variations. Since each would require an option variable somewhere it makes configuration imposing and the code more complicated and hence slower. On the other hand it would be nice to have someway of giving everyone what they want. I do have some ideas about how to do that but would like to discuss it with others such as yourself hence the discussion topic #65 .

from ojg.