Make width adapt window size.

[scherermichael]

I have found that the usage is always displayed with 80 characters width. Hence I slightly adjusted your code, so that it makes use of the actual width of the terminal - or falls back to 80 characters, if the width of the terminal can not be retrieved.

I hope you like this idea 😊

[75lb]

thanks, but what if I'm using a large monitor with a 200-column terminal? It would look terrible. In general, 80 columns is a "readable" width

[75lb]

i forgot to mention that the usage guide width is configurable.

This example shows how to pass options to the underlying table-layout module. The option you want is maxWidth.

[goloroden]

Hmm … it's sad that this was closed without any further discussion 😢

It's not only about 200-column wide terminals - there are also people with terminals with less than 80 characters width. What about them? The current layout looks pretty much broken, so while I can understand your point, IMHO it would nevertheless be a good idea to have a more intelligent logic than just 80 chars fixed.

What about something such as the maximum of 80 characters and the actual width for smaller terminals? Is there any room for discussion, or is it 80 characters fixed, go live with it?

(I don't want to be disrespectful, so please don't get me wrong, but 80 chars simply doesn't work for everyone.)

PS: Or, maybe it could be configurable, and if the user does not specify anything else, the default is 80, so for you it keeps working the same way, but if people have different needs, they can change things to better suit their needs?

PPS: Regarding your comment with maxWidth - does this only work for table layouts, or generally?

[75lb]

@goloroden did you miss my earlier message (above your reply)? It is configurable, it is not fixed. I posted a link to the relevant part of the docs. I will improve the docs soon, it's on the list of things to do.

An example of a usage section with a maxWidth of 40:

const usage = commandLineUsage([
  {
    header: 'A typical app',
    content: {
      options: { maxWidth: 40 },
      data: [
        { col: 'Generates something [italic]{very} important. This is a rather long, but ultimately inconsequential description intended solely to demonstrate description appearance. ' }
      ]
    }
  }
])

Output:

A typical app

  Generates something very important.
  This is a rather long, but ultimately
  inconsequential description intended
  solely to demonstrate description
  appearance.

However, an optionList section currently has fixed dimensions which is a problem. This will be fixed in the next version.

[goloroden]

Thanks for your reply, we will have a look at this, and check whether this works for us.

[goloroden]

@75lb Regarding your comment:

However, an optionList section currently has fixed dimensions which is a problem. This will be fixed in the next version.

Any news on this?

[75lb]

Hi @goloroden , I'm afraid I haven't had time to reach this issue yet. Are you still working around it, or did you a fork which does what you need?

[goloroden]

We are still working around it, but this PR would have solved the issue ;-)

[75lb]

solved for you, maybe.. but to land this PR would give a nasty shock to the many other users.. (their usage guide would suddenly look broken, switching from a readable 80 column width to 200 column or whatever size their terminal is, which is often large).. the solution is to make it configurable - that's the PR i need (to suit everyone).

[goloroden]

I think one problem with this PR is that it has just been closed. There was no sign that you would be interested in a configuration option, it was just closed because you mentioned that it would look terrible on a 200-column screen.

Maybe not the best way to handle a PR :-/

[75lb]

this is not the PR we need but you're right, there was no formal issue raised which i've done here.. apologies this isn't fixed yet, had a mad busy summer so far..

[75lb]

this was resolved in the v5 release.