Please split this into two.

First, the silent misparse. In command_line_scan() the long options are
compared with a prefix:

		else if (STRNICMP(argv[0] + argv_idx, "servername", 10) == 0

--servername=test enters that branch and swallows the next argument as its
value. early_arg_scan(), which reads the value, compares with STRICMP()
and does not recognise the same argument, so the name is never set. That is
why --clientserver is eaten and socket is left as a file name, and why
nothing is reported: mainerr(ME_UNKNOWN_OPTION) is never reached.

Please fix that on its own, in a patch that does nothing else: make those
comparisons require the name to end there, so that --servername=test becomes
"Unknown option". It is a small change and the trap is gone.

Second, --option=value support. Vim has no long option that takes a value
with = today, and the form is not documented anywhere, so this adds a new
convention rather than fills a gap.

Which raises the question: once the misparse is fixed, is the feature still
needed? Both examples in the description go wrong because nothing is reported.
With "Unknown option" the mistake is visible at once, and the answer is to
write --servername test. If there is a reason to accept = beyond that,
please say what it is, and let it be discussed on its own rather than as part
of a bug fix.

#21088

I think key=val commandline is so adopted that I can't think of any other program not supporting it, that would be some odd builtin or little used software.

I think key=val commandline is so adopted that I can't think of any other program not supporting it, that would be some odd builtin or little used software.

[doug] /tmp % python3 --check-hash-based-pycs=default
unknown option --check-hash-based-pycs=default
usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.
[doug] /tmp % python3 --check-hash-based-pycs default
Python 3.10.12 (main, Jun 22 2026, 18:55:27) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

[doug] /tmp % curl example.com --silent --output=outfile
curl: option --output=outfile: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
[doug] /tmp % curl example.com --silent --output outfile
[doug] /tmp %

Ubiquity is not a strong argument. Are there any ambiguous option combinations that this would fix?

This works here, must be an older version.

[doug] /tmp % curl example.com --silent --output=outfile
curl: option --output=outfile: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
[doug] /tmp % curl example.com --silent --output outfile
[doug] /tmp %

Ubiquity is not a strong argument. Are there any ambiguous option combinations that this would fix?

Its easier to read.

They were just the first two that I used after reading your PR and being non-GNU thought they might not support the =.

This works here, must be an older version.

For reference: https://daniel.haxx.se/blog/2025/07/31/option-parsing-in-curl/

I don't have a strong objection to adding this but it would be nice to have a real functional justification and skimming :help startup-options I can't see one. One advantage of = is that it disambiguates optional values from arguments but that doesn't seem to apply in our case as optional values require no intervening whitespace or a + prefix.

If one is used to the other way it can take a few tries to get it right and I think thats a few too many, but I'll gladly see if I can simplify this code if I can.