WIP: Web.JSON improve to v8

[Milly]

Web.JSON is too old.
Update to vim 8.

...But since json_encode() already exists, is this module unnecessary?

This PR includes these new featues.

• 'allow_nan' setting.
• 'ensure_ascii' setting.
• 'from_encoding' setting.

[lambdalisue]

From my point of view, at least this module should keep backward compatibility while

1. People should use json_encode() instead as you said
2. That's why there is no positive reason to improve this module
3. Code which uses this module uses this module may because of some reason

[Milly]

1. People should use json_encode() instead as you said

Vital.vim is currently (basically) support vim 8.0 or later.
So should this module be deprecated?
Write to document "deprecated" and "should use json_encode()"?

2. That's why there is no positive reason to improve this module

I'm thinking of an implementation that makes the JSON module more flexible like Python's JSON Library.
json_encode() is not-strict and not-flexible.
Should this be a separate module? (eg. Data.JSON or ...)

3. Code which uses this module uses this module may because of some reason

Agree

One thing, These are purely bug fixes.

• Convert control chars. (Encoded invalid JSON)
• Convert UTF-16 surrogate pairs. (Can not decode valid JSON)

[lambdalisue]

So should this module be deprecated?
Write to document "deprecated" and "should use json_encode()"?

Yeah, I think so but it's just my opinion. Actually, I'm more welcome to remove this module rather than improve/fix because of existnace of json_encode().

I'm thinking of an implementation that makes the JSON module more flexible like Python's JSON Library.
json_encode() is not-strict and not-flexible.
Should this be a separate module?

Got it. Well, then I think it's better to

1. Use different namespace as you said (I'm OK with Data.JSON)
2. Remove any codes for backward compatibilities and explain the benefits of using Data.JSON over json_encode() or whatever in help
3. Apply bug fixes to Web.JSON (Optional, if you desire)

[tsuyoshicho]

I Think Changes OK.

But. If you review result read and think to need changing.

• Vim.Type use or not
• add Changes

---

項目がのこったままになってる面があったので、レビューがんばってみました。
(ありすえさん指摘の点をどうするかは別として、内容自体は問題ないと思います。(自信は微妙ですが))

そのまますすめるにしても、指摘点についてどうするか確認の意味もあり、 Request changes で返しています。

[tsuyoshicho]

This point is incompatible changing. need appending item to Changes.

Please Changes appending to commit after all changes are done, and before PR merging.

[Milly]

Is the point you say Add 'allow_nan' or Remove 'use_token'?

[tsuyoshicho]

Yes.

I think, Adding phrase to Changes for example Improve and *use_token* remove, and option renewal to support *allow_nan* .

[Milly]

I'm created #743 that part of bug fixes of this PR.

[mattn]

Closed by #743 ?

[Milly]

@mattn

Closed by #743 ?

It's includes only bug fixes that is part of this.

I'm rebased, skip these commits and force pushed.

[lambdalisue]

Sorry for late. I think it would be better to add a new one like Data.JSON or whatever and mark this module obsolete but while the code seems OK, approved 👍 I don't care if this PR is merged as-is if others do not care about my point of view.