[BUG] Too many attribute aliase names in Plots API. They should be dropped or allow max 1 alias per attribute.

[EldarAgalarov]

There are too many attribute aliases in Plots API. For what? API should be clean and simple as possible.

Just need to pick one good, clean and short-as-possible attribute name.
Rest aliases should be deprecated/dropped as they making code reading harder and harder to remember they all.
As compromise maximum 1 alias name should be allowed.

[BioTurboNick]

Can you justify why this is a bug to you? Having flexible choices to minimize documentation lookup is part of the design philosophy of Plots.

[EldarAgalarov]

Having flexible choices to minimize documentation lookup is part of the design philosophy of Plots.

How having zillion of aliases can minimize documentation lookup? Maybe opposite - it maximizes documentation lookup? Having one name I must remember just one name, having multiple names, I should always go to documentation and look what this attribute name means if I see it first time.

Following your logic, why do not make aliases for functions too? They aren't worse than attributes. For example let's make aliases for plot function: draw_plot, draw_chart, chartdraw, chart_draw, do_plot, do_chart, etc :)

[BioTurboNick]

Having flexible choices to minimize documentation lookup is part of the design philosophy of Plots.

How having zillion of aliases can minimize documentation lookup? Maybe opposite - it maximizes documentation lookup? Having one name I must remember just one name, having multiple names, I should always go to documentation and look what this attribute name means if I see it first time.

It's meant for writing quickly and interactively, not reading. There is a canonical variant for each argument that is recommended for API use.

And there are shorthands for other plot calls. xlims! for plot!(xlims = ), for example, or scatter for plot(seriestype = :scatter).

[BioTurboNick]

Playing Devil's Advocate for a moment -

Would it be a good idea to have an overlay module that provides the convenience arguments and functions, which could be excluded if desired? Or automatically imported only in a REPL context, so that non-interactive uses are prodded towards a uniform API?