@Skeeve Thank you, could you please take a look

@Skeeve Thank you, could you please take a look

I can, but I cannot approve.

It's currently possible to get the following help output with the Usage field:

Usage: "string"
Output:
   --bar value  string

Usage: "`string`"
Output:
   --bar string  string

I think either one of those cases could be changed to overwrite the placeholder without setting a usage.

This whole section is questionable.

The unquoteUsage() function parses flag value type from the usage (!) string (#333). I am +1 on dropping this workaround if this PR works.

I didn't know this was a workaround to get stdlib flag functionality. Might I add two points to consider:

• If the interface method were Type() string it would allow inter-op with pflag's Value interface.
• reflect.Type.Name() works for strings, numbers and bools but returns the empty string for slices and maps. I think for those the default value should still apply.

Thanks all @avorima @abitrolly @Skeeve . I will make a summary based on your suggestions and explain my ideas ,

1. I would like to keep that method https://github.com/urfave/cli/issues/333 , because somebody may want to custom flag type by themself .
2. If reflect.Type.Name() is not enough for get all base type , I will try to use other method.

my next step will be:

1. Improve this code to ensure that all basic types can be displayed, and ensure that custom priority is > the default flag type (like string., bool , etc )priority.
2. Fix CI
3. Fix doc

• If the interface method were Type() string it would allow inter-op with pflag's Value interface.

That's a nice idea , May I consider it . From the current perspective, using reflection should be sufficient.

0cb6639#diff-f09230a06a76ff761bbdcc9b788aa057cc5caa463f1bd68e67b14422938622d4R110

I think the "[]" is of no additional value and should be omitted.

1. Brackets have a well known meaning in usage texts. They are confusing here
2. Slice flags are no different from non-slice flags. There is no special parameter syntax for them

I think you should avoid the "[]" marker.

0cb6639#diff-f09230a06a76ff761bbdcc9b788aa057cc5caa463f1bd68e67b14422938622d4R110

I think the "[]" is of no additional value and should be omitted.

1. Brackets have a well known meaning in usage texts. They are confusing here
2. Slice flags are no different from non-slice flags. There is no special parameter syntax for them

I think you should avoid the "[]" marker.

That's for these type like UintSliceFlag's flag can print '[]uint64' and reflect.Type.Name() can't return the slice type . Or may I print like this 'uint64s' for different from 'uint64' type?

That's for these type like UintSliceFlag's flag can print '[]uint64' and reflect.Type.Name() can't return the slice type . Or may I print like this 'uint64s' for different from 'uint64' type?

Why would you want to distinguish a uint64 from a slice of uint64. It transfers no additional meaning to the reader. If a flag is a slice flag, the only difference in usage is, that you can use the flag several times. This is usually stated in the usage text.

That's for these type like UintSliceFlag's flag can print '[]uint64' and reflect.Type.Name() can't return the slice type . Or may I print like this 'uint64s' for different from 'uint64' type?

Why would you want to distinguish a uint64 from a slice of uint64. It transfers no additional meaning to the reader. If a flag is a slice flag, the only difference in usage is, that you can use the flag several times. This is usually stated in the usage text.

You're right. How about just print the slice type ?
example:

Flags: []cli.Flag{
			&cli.StringSliceFlag{
				Name:  "greeting",
				Usage: "Pass multiple greetings",
			},
		},

=> --greeting string [ --greeting string ] Pass multiple greetings

Actually, the placeholder hack is documented https://cli.urfave.org/v3/examples/flags/#placeholder-values

Maybe it doesn't need to be overcomplicated. Maybe stub basic types and provide an extension to explicitly format placeholder name for other things.

Actually, the placeholder hack is documented https://cli.urfave.org/v3/examples/flags/#placeholder-values

Maybe it doesn't need to be overcomplicated. Maybe stub basic types and provide an extension to explicitly format placeholder name for other things.

Sorry, I didn't understand. Can you be more detailed. If it means do not use reflection , Do you directly give the name of the flag type when initializing the flag？

@Skeeve I've changed in new commit , may be it looks greater.

@Scutua say something.