iniconf: some more adjustments for parsing TOML

[techee]

These two patches:

• improve parsing of TOML [[arrays_of_tables]]
• support 'single quoted keys' = true and "double quoted keys" = true

See the individual commits for more details.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 85.85%. Comparing base (ecf0c4a) to head (ae09350). Report is 20 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4099      +/-   ##
==========================================
+ Coverage   85.72%   85.85%   +0.12%     
==========================================
  Files         239      239              
  Lines       56961    58629    +1668     
==========================================
+ Hits        48827    50333    +1506     
- Misses       8134     8296     +162     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[techee]

@masatake Any opinion on this pull request?

[masatake]

Sorry for the late reply.

My primary question is whether this pull request intends a bug fix or a hack for adjusting the Iniconf parser to TOML.

We provide a PEG-based TOML parser. So modifying the Iniconf parser for supporting TOML is not a standard practice. This is my baseline to evaluate this pull request.

On the other hand, the TOML parser doesn't work well (#4096). As you were afraid, I'm not familiar with PEG enough so I have not fixed the simple bug yet. So I don't ask you to use the TOMP parser. Hacking Iniconf for supporting TOML makes sense.

But this is still a hack. So I have some requests. Please, see my review comments.

[techee]

My primary question is whether this pull request intends a bug fix or a hack for adjusting the Iniconf parser to TOML.

You are right, I want to use this parser for parsing TOML in Geany so it's kind of hack. On the other hand, it's not such a hack - there's no formal ini specification so I think what I propose is still a valid ini. The way I understand ini files intuitively is:

1. [section name]\n for sections
2. whatever=whatever\n for value assignments

So in fact, I believe the key name it could be any character sequence (with stripped leading and trailing spaces). And for the section name it should be the first [ and the last ] that count as section delimiters, the rest is the section name.

In any case, no problem to add the changes you propose.

[masatake]

Thank you for updating. I have one more request to change. See my comment.

On the other hand, it's not such a hack - there's no formal ini specification so I think what I propose is still a valid ini.

I see. However, the updated version of this pull request looks more understandable.

[masatake]

Thank you.